Estou escrevendo um filtro de rede muito simples e chegando ao ponto em que desejo analisar os cabeçalhos IPv6 para corresponder a coisas como tipos ICMPv6, números de porta TCP / UDP etc.
Então, estou lendo sobre o formato de pacote IPv6 em profundidade, e eu meio que ... bem ... Eu meio que tive que ler várias vezes para ter certeza de que estava realmente lendo direito. Parece-me que você precisa começar com o cabeçalho fixo de 40 bytes e examinar o próximo campo de cabeçalho. Em seguida, você deve olhar para o próximo campo de cabeçalho do próximo cabeçalho e assim por diante, como uma lista vinculada, até chegar ao fim. Se houver carga útil, ela seguirá.
O problema é que não há campo de comprimento no cabeçalho fixo ou nos cabeçalhos de extensão. Você tem que ter uma tabela de tipos de cabeçalho de extensão e seus tamanhos para que você possa perseguir esta lista vinculada até o fim.
Isso me parece um desenho estranho, possivelmente até mesmo desmiolado. E se eu encontrar um tipo de cabeçalho de extensão não reconhecido? O que eu faço? Não sei seu comprimento. Acho que tenho que jogar o pacote fora e bloqueá-lo, já que em um filtro de rede, permitir a passagem do pacote permitiria a um invasor escapar do filtro de rede incluindo um tipo de cabeçalho falso. Mas isso significa que, se o protocolo for estendido, cada pedaço do software de análise de cabeçalho IPv6 já escrito deve ser atualizado simultaneamente se a nova extensão for usada.
Então, como posso analisar os cabeçalhos IPv6 se não sei as extensões que eles estão usando? Como posso pular um cabeçalho para uma extensão desconhecida, já que não sei seu comprimento?
fonte
Respostas:
Se você se deparar com algo que não pode analisar, terá que tomar sua decisão ou executar sua ação com base no que já analisou.
O design é assim porque no IPv6, cada cabeçalho de extensão "envolve" o resto do pacote. Se você vir o cabeçalho de roteamento, então algum cabeçalho que você nunca ouviu falar, então a carga útil, então você não pode analisar a carga útil. O significado da carga útil depende, em princípio, do cabeçalho que você não sabe como interpretar.
Os roteadores podem rotear esses pacotes, porque tudo de que precisam é o cabeçalho de roteamento. Dispositivos de inspeção profunda de pacotes e afins precisam saber muito, mas esse é o destino deles de qualquer maneira.
Editado para adicionar: Este design significa que middleboxes só podem mudar o que sabem. Se um middlebox vir um cabeçalho que não conhece, então terá apenas duas opções: Rejeitar ou passar adiante. No IPv4, ele também pode remover a extensão desconhecida e passar o resto adiante. IMO esta propriedade torna o design mais ao invés de menos extensível.
fonte
Da RFC 2460 :
fonte
With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.Incorreto, porque:
Apenas o host de destino pode rejeitar com base em cabeçalhos de extensões não reconhecidos (com aquela única exceção mencionada na pergunta que você vinculou )
Se o seu novo cabeçalho de extensão for de alguma forma opcional (é melhor que seja), você receberá um erro ICMP sobre isso e poderá tentar novamente sem ele.
fonte
A atualização RFC 6564 cobre esse caso. Ele apresenta exatamente o cenário que você descreve e apresenta um formato para quaisquer novos cabeçalhos de extensão (se algum for definido) com os quais caixas intermediárias como a sua serão capazes de trabalhar, pelo menos por algum tempo.
Lembre-se de que a intenção não é estender o IPv6 criando novos cabeçalhos de extensão, mas adicionando novas opções de destino. Deve ser trivial, ou pelo menos muito mais fácil, para você lidar com opções de destino desconhecidas.
fonte