INSTITUTO SUPERIOR DE ENGENHARIA DE LISBOA
Departamento de Engenharia de Electrónica e Telecomunicações e
de Computadores
ISEL
Exploração da implementação actual de IPv6 no
kernel do Linux
Márcio Moeda
(Licenciado)
Trabalho de projecto realizado para obtenção do grau de Mestre em
Engenharia Informática e de Computadores
Orientador:
Professor adjunto Pedro Ribeiro, ISEL
Júri:
Presidente: Professor adjunto Vítor Almeida, ISEL
Vogais:
Professor adjunto João Ascenso, ISEL
Março de 2011
Exploração da Implementação actual de IPv6 no Kernel do Linux ii
Agradecimentos
Em primeiro lugar agradeço o meu orientador Pedro Ribeiro, pelo acompanhamento,
auxílio e disponibilidade que mostrou durante todo este período.
Agradeço o apoio de toda a minha família e dos meus amigos, e em especial dos meus
pais pelo incondicional apoio e permanente incentivo que tenho recebido ao longo dos
anos.
Agradeço a todas as pessoas que contribuíram para a concretização desta dissertação.
Finalmente, um agradecimento especial à Sheila Maritza T. P. Monteiro pelo amor, apoio,
incentivo e pela enorme ajuda que me deu ao ajudar na correcção do trabalho.
A todos muito Obrigado.
Exploração da Implementação actual de IPv6 no Kernel do Linux iii
Resumo
A presente dissertação visa retratar a exploração do suporte do protocolo Internet
versão seis (IPv6) no kernel do Linux, conjuntamente com a análise detalhada do estado
da implementação dos diferentes aspectos em que se baseia o protocolo.
O estudo incide na experimentação do funcionamento em geral do stack, a identificação
de inconsistências deste em relação aos RFC’s1 respectivos, bem como a simulação
laboratorial de cenários que reproduzam casos de utilização de cada uma das facilidades
analisadas.
O objectivo desta dissertação não é explicar o funcionamento do novo protocolo IPv6,
mas antes, centrar-se essencialmente na exploração do IPv6 no kernel do Linux. Não é
um documento para leigos em IPv6, no entanto, optou-se por desenvolver uma parte
inicial onde é abordado o essencial do protocolo: a sua evolução até à aprovação e a sua
especificação.
Com base no estudo realizado, explora-se o suporte do IPv6 no Kernel do Linux, fazendo
uma análise detalhada do estado de implementação dos diferentes aspectos em que se
baseia o protocolo. Bem como a realização de testes de conformidade IPv6 em relação
aos RFC’s.
1 RFC é um acrónimo para o inglês Request for Comments, é um documento que descreve os
padrões dos protocolos propostos para a Internet antes de serem considerados um standard.
Exploração da Implementação actual de IPv6 no Kernel do Linux iv
Abstract
The aim of this dissertation is to describe the support exploration protocol of Internet
version six (IPv6) in the Linux kernel in conjunction with a detailed analysis of the
implementation state of the different aspects on which the protocol is based.
This study focuses on the general working experimentation of stack, the identification of
its inconsistencies in relation to the corresponding RFCs as well as laboratory simulation
of scenarios, which reproduce instances of use of each of the facilities analyzed.
The goal of this dissertation is not to explain how the new IPv6 protocol works; rather, it
focuses primarily on the exploration of Linux’ IPv6 kernel. This is not a document for
people who are not familiar with IPv6. However, we opted to develop an initial part in
which we address the fundamentals of the protocol namely, its evolution and approval and
its specification.
Based on this study, we explore the support of IPv6 in Linux’ Kernel through a detailed
analysis of the implementation state of the different aspects on which this protocol is
based. Also, conformity tests were conducted in relation to RFC’s.
Exploração da Implementação actual de IPv6 no Kernel do Linux v
Acrónimos
TN Nó que realiza o teste
NUT Nó que é testado
NA Neighbor Advertisement
NS Neighbor Solicitation
ICMPv6 Internet Control Message Protocol for the Internet Protocol Version 6
PDU Protocol Data Unit
USAGI UniverSAL playGround for IPv6
SIP Simple Internet Protocol
PIP ―P‖ Internet Protocol
SIPP The Simple Internet Protocol Plus
IPAE IP Address Encapsulation
TUBA TCP and UDP with Bigger Addresses
CATNIP Common Architecture for the Internet
IPng IP Next Generation Protocol
IESG Internet Engineering Steering Group
IANA Internet Assigned Numbers Authority
ICANN Internet Corporation for Assigned Names and Numbers
ARPANET Advanced Research Projects Agency Network
QoS Quality of Service
CIDR Classless InterDomain Routing
NAT Network Address Translation
Exploração da Implementação actual de IPv6 no Kernel do Linux vi
Índice
Agradecimentos ................................................................................................................. ii
Resumo ............................................................................................................................ iii
Abstract ............................................................................................................................ iv
Acrónimos.......................................................................................................................... v
Índice ................................................................................................................................ vi
Índice de Figuras ............................................................................................................... x
Índice de tabelas............................................................................................................... xi
Capítulo I ......................................................................................................................... 13
Considerações Gerais ..................................................................................................... 13
1.1. Introdução .........................................................................................................13
1.2. Pergunta de partida ou problema da investigação .............................................15
1.3. Objectivos ..........................................................................................................16
1.4. Síntese dos capítulos ........................................................................................17
Capítulo II ........................................................................................................................ 18
IPv6 ................................................................................................................................. 18
1.1. Considerações Gerais .......................................................................................18
1.2. Evolução do Protocolo Internet (IPv6) ................................................................19
1.3. Porquê o IPv6? ..................................................................................................22
1.4. Limitações do IPv4 ............................................................................................23
1.5. Especificação do IPv6 .......................................................................................26
Simplificação do cabeçalho ......................................................................................28
Capítulo III ....................................................................................................................... 31
Ferramenta de conformidade da especificação IPv6 ....................................................... 31
1.1. Considerações Gerais .......................................................................................31
1.2. Procedimento comum de limpeza dos testes .....................................................33
1.3. Definição da estrutura do pacote .......................................................................33
1.4. Exemplos de Funções Disponíveis na API ........................................................34
Exploração da Implementação actual de IPv6 no Kernel do Linux vii
Capítulo IV ....................................................................................................................... 36
Descrição dos testes IPv6 realizados .............................................................................. 36
1. Considerações Gerais ...........................................................................................36
2. Testes em relação à especificação base do IPv6 ..................................................37
2.1. Teste ao Campo Versão (Version Field).........................................................37
2.1.1. Objectivo .................................................................................................37
2.1.2. Corpo do Teste .......................................................................................37
2.1.3. Resultado esperado do Teste .................................................................40
2.2. Teste ao campo Traffic Class .........................................................................40
2.2.1. Objectivo .................................................................................................41
2.2.2. Corpo do Teste .......................................................................................41
2.2.3. Resultado esperado do Teste .................................................................42
2.3. Teste ao campo Flow Label ...........................................................................42
2.3.1. Objectivo .................................................................................................43
2.3.2. Corpo do Teste .......................................................................................43
2.3.3. Resultado do Teste .................................................................................44
2.4. Teste ao campo Payload Length ....................................................................44
2.4.1. Objectivo .................................................................................................44
2.4.2. Corpo do Teste .......................................................................................44
2.4.3. Resultado esperado do Teste .................................................................46
2.5. Teste campo Next Header irreconhecível .......................................................46
2.5.1. Objectivo .................................................................................................47
2.5.2. Corpo do Teste .......................................................................................47
2.5.3. Resultado esperado do Teste .................................................................49
2.6. Teste campo Hop Limit igual a zero ...............................................................49
2.6.1. Objectivo .................................................................................................49
2.6.2. Corpo do Teste .......................................................................................49
2.6.3. Resultado esperado do Teste .................................................................51
3. Testes referentes ao processamento das Opções e Cabeçalhos de Extensões ....51
3.1. Pacote Echo Request usado nos testes .........................................................53
3.2. Teste ao campo Next Header do cabeçalho de Extensão ..............................54
3.2.1. Objectivo .................................................................................................54
3.2.2. Corpo do teste ........................................................................................54
Exploração da Implementação actual de IPv6 no Kernel do Linux viii
3.2.3. Resultado esperado do teste ..................................................................55
3.3. Teste à ordem do cabeçalho de extensão Hop-by-Hop num pacote com mais
de um cabeçalho extensão .......................................................................................56
3.3.1. Objectivo .................................................................................................57
3.3.2. Corpo do teste ........................................................................................57
3.3.3. Resultado esperado do teste ..................................................................59
3.4. Teste ao cabeçalho de extensão Hop-by-Hop ................................................59
3.5. Teste ao campo Opção Pad1/PadN do cabeçalho de extensão Hop-by-Hop
62
3.5.1. Objectivo .............................................................................................63
3.5.2. Corpo do teste .....................................................................................63
3.5.3. Resultado esperado do teste ...............................................................65
3.6. Teste à codificação dos dois bits de maior ordem do indicador Option Type
66
3.6.1. Objectivo .............................................................................................67
3.6.2. Corpo do Teste ....................................................................................67
3.6.3. Resultado esperado do teste ...............................................................69
4. Testes referentes à fragmentação no IPv6 ............................................................69
4.1. Fragmentos de pacote usados nos testes ......................................................74
4.2. Teste à reconstituição de fragmentos (ordem normal/ ordem inversa) ...........75
4.2.1. Objectivo .................................................................................................75
4.2.2. Corpo do teste ........................................................................................75
4.2.3. Resultado esperado do teste ..................................................................77
4.3. Teste à reconstituição de fragmentos (Payload size = 65.536 bytes) .............77
4.3.1. Objectivo .................................................................................................77
4.3.2. Corpo do teste ........................................................................................77
4.3.3. Resultado esperado do teste ..................................................................78
4.4. Teste à reconstituição de fragmentos quando é excedido o tempo (1st only) .78
4.4.1. Objectivo .................................................................................................79
4.4.2. Corpo do teste ........................................................................................79
4.4.3. Resultado esperado do teste ..................................................................79
Capítulo V ........................................................................................................................ 80
Resultado dos Testes Realizados .................................................................................... 80
1.1. Considerações Gerais .......................................................................................80
Exploração da Implementação actual de IPv6 no Kernel do Linux ix
1.2. Resultado dos testes .........................................................................................80
1.3. Análise dos resultados .......................................................................................82
1.4. Comparação entre sistemas operativos .............................................................85
Capítulo VI ....................................................................................................................... 87
Conclusão........................................................................................................................ 87
1.1. Considerações Gerais .......................................................................................87
1.2. Verificação das hipóteses teóricas e práticas ....................................................87
1.3. Limitações da Investigação ................................................................................88
1.4. Investigações futuras .........................................................................................88
Bibliografia ....................................................................................................................... 89
Exploração da Implementação actual de IPv6 no Kernel do Linux x
Índice de Figuras
Figura 1 - Linux Kernel 2.1.8. ...........................................................................................15
Figura 2 - Crescimento da internet ...................................................................................24
Figura 3 - Cabeçalho IPv4. ..............................................................................................28
Figura 4 - Cabeçalho IPv6. ..............................................................................................28
Figura 5 - Programa de execução Automática .................................................................33
Figura 6 - Cabeçalho de Extensão ...................................................................................52
Figura 7 - Cabeçalho Hop-by-Hop Option ........................................................................59
Figura 8 - Captura do Cabeçalho Hop-by-Hop Option ......................................................59
Figura 9 - Formato do campo opções. .............................................................................61
Figura 10 - Valor do tipo de opção Pad1 de um pacote IPv6 ...........................................62
Figura 11 - PadN Option. .................................................................................................62
Figura 12 - Cabeçalho de Extensão Fragmentation .........................................................70
Figura 13 - Fragmentação de pacotes. ............................................................................71
Figura 14 - Pacote original. ..............................................................................................71
Figura 15 - Pacotes fragmentados. ..................................................................................72
Exploração da Implementação actual de IPv6 no Kernel do Linux xi
Índice de tabelas
Tabela 1 - Script de teste disponível ................................................................................32
Tabela 2 - Script Status Code ..........................................................................................34
Tabela 3 - Funções disponíveis na API ............................................................................34
Tabela 4 - Exemplo vSend ...............................................................................................35
Tabela 5 - Exemplo vRec .................................................................................................35
Tabela 6 - Funções do script IH_BadIPv6Ver.seq ............................................................38
Tabela 7 - Pacotes gerados pelo script IH_BadIPv6Ver.seq ............................................39
Tabela 8 - Acções executadas no teste ao campo Versão ...............................................39
Tabela 9 - Função do script TC_NonZeroToHost.seq ......................................................41
Tabela 10 - Acções executadas no teste ao campo Traffic Class ....................................42
Tabela 11 - Função do script FL_NonZeroToHost.seq .....................................................43
Tabela 12 - Acções executadas no teste ao campo Flow Label .......................................44
Tabela 13 - Função do script PL_OddToHost.seq ...........................................................45
Tabela 14 - Pacote gerado pelo script PL_OddToHost.seq .............................................45
Tabela 15 - Acções executadas no teste ao Campo Payload Length ...............................46
Tabela 16 - Alguns valores possíveis que o campo Next Header pode assumir ..............47
Tabela 17- Função do script IH_UnrecognizedNextHeader.seq .......................................48
Tabela 18 - Pacote gerado pelo script IH_UnrecognizedNextHeader.seq ........................48
Tabela 19 - Acções executadas no teste ao campo Next Header ....................................49
Tabela 20 - Função do script HL_ZeroToHost.seq ...........................................................50
Tabela 21 - Acções executadas no teste ao campo Hop Limit .........................................50
Tabela 22 - Cabeçalho de Extensão ................................................................................52
Tabela 23 - Pacote Echo Request usado nos testes ao Cabeçalho de extensão .............53
Tabela 24- Função do script EH_UnrecognizedNextHeader.seq .....................................54
Tabela 25 - Pacote gerado pelo script EH_UnrecognizedNextHeader.seq ......................55
Exploração da Implementação actual de IPv6 no Kernel do Linux xii
Tabela 26 - Acções executadas no teste ao campo Next Header do cabeçalho de
extensão ..........................................................................................................................55
Tabela 27 - Ordem dos Cabeçalhos de Extensão ............................................................56
Tabela 28 - Função do script EH_HBHOptAfterDstOpt.seq .............................................57
Tabela 29 - Pacote gerado pelo script EH_HBHOptAfterDstOpt.seq ...............................58
Tabela 30 - Acções executadas no teste à ordem do cabeçalho de extensão Hop-by-Hop
........................................................................................................................................58
Tabela 31 - Função do script EH_HBHOptAfterDstOpt.seq .............................................63
Tabela 32 - Pacote gerado pelo script HH_Pad1.seq e HH_PadN.seq ............................64
Tabela 33 - Acções executadas no teste ao campo Opção Pad1/PadN ..........................65
Tabela 34 - Identificadores Option Type ..........................................................................66
Tabela 35 - Terceiro bit mais significativo do Option Type ...............................................66
Tabela 36 - Primitivas usadas no script HH_Type.seq .....................................................68
Tabela 37 - Pacotes gerados pelo script HH_Type.seq ...................................................68
Tabela 38 - Bit M do cabeçalho de extensão Fragment ...................................................70
Tabela 39 - Fragmentos de um Pacote Echo Request usado nos testes à fragmentação 74
Tabela 40 - Primitivas usadas para gerar fragmentos de um pacote ................................76
Tabela 41 - Acções executadas no teste ao campo Opção Pad1/PadN ..........................78
Tabela 42- Acções executadas no teste à reconstituição de fragmentos .........................79
Tabela 43 - Resultado dos Testes de Conformidade IPv6 realizados ..............................81
Tabela 44 - Teste de Conformidade IPv6 à distribuição Ubuntu e FreeBSD ....................85
Exploração da Implementação actual de IPv6 no Kernel do Linux 13
Capítulo I
Considerações Gerais
1.1. Introdução
A Internet, que na sociedade actual, assume um papel preponderante, surgiu da
necessidade de ligar computadores de forma a permitir e facilitar a partilha da
informação. O protocolo Internet (IP) é o responsável pelo transporte de dados na
internet. Existem duas variantes deste protocolo: IPv4 e IPv6.
Desde que a primeira versão do protocolo IP (IPv4) foi desenvolvida, o poder de
processamento das máquinas cresceu muito. Com o crescimento rápido da Internet, esta
tecnologia (IPv4) tem-se esgotado e muitos esforços têm sido feitos para a sua evolução.
Neste cenário é premente a necessidade de serem criadas alternativas para a solução de
problemas que começaram a surgir. A escassez de endereçamento IP para alguns
continentes, a necessidade de tratamento diferenciado aos fluxos de tráfego de serviços
em tempo real e aspectos ligados à segurança, fizeram com que os órgãos internacionais
ligados a essas matérias e os responsáveis pela elaboração das especificações do
protocolo IPv4 tivessem as suas atenções voltadas para um novo estudo.
Em 1993, o IESG2 (Internet Engineering Steering Group) criou um grupo de trabalho para
uma nova versão do protocolo IP, o IPngWG (IP Next Generation Working Group), com
base em alguns objectivos que deveriam ser alcançados.
2 O IESG é responsável pela gestão técnica das actividades IETF. http://www.ietf.org/iesg/
Capítulo I – Considerações Gerias
Exploração da Implementação actual de IPv6 no Kernel do Linux 14
O grupo de trabalho seleccionou três protocolos para a camada de rede da arquitectura
TCP/IP.
O primeiro designado de IPAE (IP Address Encapsulation), o segundo designado de SIP
(Simple Internet Protocol) e o terceiro designado de PIP (“P” Internet Protocol). A
combinação de aspectos positivos dos três protocolos deu origem a um novo protocolo
designado de SIPP (Simple Internet Protocol Plus).
O protocolo indicado pelo grupo foi o SIPP3 (Simple Internet Protocol Plus), por ser o
mais próximo do IPv4, e por ter um plano de transição melhor.
O protocolo IPv6 é uma nova versão do protocolo IP. A base do IPv6 é o IPv4, isto é, foi
criado sobre uma plataforma comprovadamente eficaz, o que é fundamental tanto para a
transição entre a versão 4 e a 6, quanto para a excelência do IPv6.
O IPv6 foi concebido numa lógica de estabilidade do sistema, assim sendo, pretendeu-se
que a transição se efectuasse de forma suave e eficaz. Este factor de transição foi tido
como um factor muito importante na altura da sua concepção. Todavia, a transição para o
IPv6 não ocorrerá de forma rápida e imediata, este cenário mais não é que uma
estratégia da nova versão do protocolo, onde se pretende uma coexistência das duas
versões por um período de tempo considerável. Durante os próximos anos, irão ocorrer
duas etapas distintas, uma primeira em que existirão pequenas redes IPv6 no universo
IPv4 (situação actual) e, seguidamente, o contrário, ou seja, quando o protocolo IPv6
estiver generalizado irão prevalecer pequenas redes IPv4 no universo IPv6.
3 Simple Internet Protocol Plus (SIPP) http://www.faqs.org/rfcs/rfc1710.html
Capítulo I – Considerações Gerias
Exploração da Implementação actual de IPv6 no Kernel do Linux 15
1.2. Pergunta de partida ou problema da investigação
O primeiro código relacionado ao IPv6 foi adicionado ao kernel do Linux na versão
2.1.8 por Pedro Roque da Faculdade de Ciências de Universidade de Lisboa, ainda com
muitas limitações4 de implementação.
Figura 1 - Linux Kernel 2.1.8.
O suporte ao IPv6, com a versão 2.2.x, passou a ser incluído no código fonte do kernel e
já ostentava maior estabilidade em relação às versões anteriores, entretanto ainda não
vinha activado por defeito. Actualmente, a maioria das distribuições Linux vem com o
suporte ao IPv6 activado e com algumas funcionalidades disponíveis, possibilitando a
utilização das principais novidades do IPv6.
A universalidade do IPv6 leva a um grande número de implementações. O IPv4,
contrariamente, começou com um pequeno grupo fechado, a interoperabilidade tem sido
sempre considerada como um elemento essencial para a comunidade da Internet.
Grande número de implementações de funcionalidades do IPv6 no kernel do Linux e de
outros sistemas operativos não acompanhou os ―Drafts‖ ou os RFC’s recém-lançados.
A ausência de manutenção fez com que algumas funcionalidades passassem a estar
desactualizadas. Para atenuação e/ou eliminação dessas falhas, foi lançado um projecto
designado por USAGI5 (UniverSAL playGround for IPv6) que trabalha em parceria com
outros projectos tais como WIDE Project, KAME Project e TAHI Project.
4 Retirado do documento do Peter Bieringer: http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6-HOWTO-
0.html 5 O projecto USAGI pode ser consultado no seguinte link: http://www.linux-ipv6.org/
Capítulo I – Considerações Gerias
Exploração da Implementação actual de IPv6 no Kernel do Linux 16
Estes projectos têm como objectivo primordial o desenvolvimento do IPv6 principalmente
para sistemas operativos Linux, isto é, visam melhorar o IPv6 no ambiente Linux e
implementar a Internet IPv6 no mundo.
Presentemente, conseguiram-se alcançar muitas melhorias no kernel, bibliotecas e
aplicativos. O resultado desse trabalho foi integrado no kernel 2.6.
1.3. Objectivos
Para a elaboração desta dissertação foram estabelecidos três objectivos gerais, sobre
os quais se definem com maior especificidade os objectivos concretos, de acordo com a
evolução verificada.
Existem objectivos ao nível do trabalho prático, sendo estes mais imediatos, uma vez
que, se prendem com a exploração do suporte de IPv6 no Kernel do Linux, com a análise
detalhada do estado de implementação dos diferentes aspectos em que se baseia o
protocolo e outros de índole mais teórica, visto que se pretende tirar conclusões sobre o
estudo/análise anteriormente referido.
O primeiro objectivo é o estudo das características e a arquitectura do protocolo IPv6.
Apresenta-se a nova versão do protocolo IP, o IPv6, descreve-se a sua evolução até a
aprovação, e, ainda, detalhadamente a sua especificação.
O segundo objectivo, consiste na exploração do suporte de IPv6 no Kernel do Linux, com
a análise detalhada do estado de implementação dos diferentes aspectos em que se
baseia o protocolo. Serão objectivos a experimentação do funcionamento em geral do
stack, a identificação de inconsistências deste em relação aos RFC’s respectivos bem
como a simulação laboratorial de cenários que reproduzam casos de utilização de cada
uma das facilidades analisadas.
O terceiro, comparação entre o suporte de IPv6 no Kernel de várias distribuições Linux e
outros sistemas operativos.
O quarto, considerações finais sobre o tema.
Capítulo I – Considerações Gerias
Exploração da Implementação actual de IPv6 no Kernel do Linux 17
1.4. Síntese dos capítulos
Esta dissertação é composta por seis (6) capítulos. Neste primeiro capítulo faz-se
uma introdução, na qual é referido o enquadramento do trabalho, bem como a referência
à organização da dissertação. A este capítulo introdutório, segue-se, no segundo
capítulo, uma análise detalhada do estado de implementação dos diferentes aspectos em
que se baseia o protocolo IPv6 no Kernel do Linux. No terceiro capítulo, faz-se uma
descrição sobre a ferramenta de testes utilizada. No quarto capítulo, realizam-se os
testes de conformidade IPv6 em relação aos RFC´s, testes esses que se incidem sobre a
especificação base do IPv6, definidos no RFC 2460. No quinto capítulo, faz-se a análise
dos resultados obtidos dos testes realizados. No sexto capítulo, faz-se as conclusões e
recomendações.
Exploração da Implementação actual de IPv6 no Kernel do Linux 18
Capítulo II
IPv6
1.1. Considerações Gerais
A internet é vista como uma tecnologia relativamente nova, embora os protocolos
e tecnologias que a fazem funcionar tenham sido desenvolvidos entre 1970 e 1980,
actualmente a maioria das redes públicas e privadas usam o IPv4. O protocolo Internet
(IP) corresponde à linguagem comum da Internet, sendo usada por todos os dispositivos
que se encontram ligados à Internet.
A versão actual do protocolo Internet, versão 4 (designado por IPv4) tem várias lacunas
que dificultam, e em alguns casos apresentam barreiras para o desenvolvimento da
Internet. A revolução trazida pelo IPv6 vem remover essas barreiras e proporcionar um
ambiente rico em recursos para o futuro da rede Global.
O protocolo IP versão 6 (o 6 corresponde ao número da versão em causa) designado de
IPv6 constitui a nova geração do protocolo base da Internet. Foi recomendada pela Área
de Administração da IPng da Internet Engineering Task Force, na reunião do IETF em
Toronto 25 de Julho de 1994 no RFC 17526. A recomendação foi aprovada pelo Internet
Engineering Steering Group, foi feita uma proposta de norma (Proposed Standard7) em
17 de Novembro de 1994.
Foi projectado para funcionar bem em redes de alto desempenho (por exemplo, Gigabit
Ethernet, ATM, etc.).
6 The Recommendation for the IP Next Generation Protocol http://www.faqs.org/rfcs/rfc1752.html
7 Proposed Standard http://playground.sun.com/ipv6/doc/ipng-recomm-proposed-standard.txt
Capítulo II – IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 19
1.2. Evolução do Protocolo Internet (IPv6)
A história em torno do IPv6 começou no início dos anos noventa, quando as
projecções indicavam que o espaço de endereçamento da Internet (endereço IPv4)
tornava um recurso cada vez mais limitado. Esta situação desafiou a comunidade da
Internet a procurar novas soluções.
O Internet Engineering Task Force (IETF) iniciou o esforço para escolher um sucessor
para o IPv4. Houve uma conjugação de esforços de vários grupos de trabalho, com vista
à exploração de possíveis soluções para as limitações de endereçamento do IPv4 e
também para fornecer funcionalidades adicionais. Deste esforço conjunto e também da
evolução de diferentes propostas da Internet Engineering Task Force (IETF) surgiu uma
nova geração do protocolo IP, designado de IP the Next Generation8, o seu nome original
foi logo substituído por IP versão 6, que é agora o nome definitivo. Os principais
arquitectos do novo protocolo foram Steven Deering e Robert Hinden9.
Cronologicamente a evolução da nova geração do protocolo IP (IPng) foi a seguinte
segundo o RFC 1752: [1]
1990 - No encontro IETF de Vancouver, Frank Solensky, Phill Gross e Sue Hares
afirmaram que à taxa de atribuição do espaço de endereçamento IPv4, às classes do tipo
B esgotariam por volta de Março de 1994. A solução seria atribuir vários endereços
classe C em vez dos endereços classe B, o que traria outro problema aumentando o
tamanho das tabelas de Routing que cresciam a um ritmo inquietante. Na incerteza de
escolher entre aceitar ou limitar a taxa de crescimento da internet, ou a interrupção da
internet alterando-a para novas técnicas ou tecnologias foi criado um novo grupo de
trabalho (ROAD)10, Cuja finalidade primordial era dirimir as duvidas existentes
1991 - A IETF forma o grupo de trabalho Routing and Addressing (ROAD) no encontro de
Santa Fé com o objectivo de encontrar uma solução para a exaustão do espaço de
endereçamento IPv4.
1992 - A Internet Association Board (IAB) apresenta o documento IP Version 7
paralelamente aos esforços do grupo de trabalho ROAD, em que recomenda à IETF a
preparação de um plano detalhado para o sucessor do protocolo IP. A IETF rejeita esta
sugestão e apresenta pedido de propostas recomendadas pelo grupo ROAD. Como
resposta a este pedido surgiram algumas propostas:
8 The Recommendation for the IP Next Generation Protocol http://tools.ietf.org/html/rfc1752
9 Grupo de trabalho IPv6 http://playground.sun.com/ipv6/
10 IESG Deliberations on Routing and Addressing http://www.ietf.org/rfc/rfc1380.txt
Capítulo II – IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 20
CNAT
IP Encaps
Nimrod
Simple CLNP
1992 (finais) – Surgem mais três propostas:
The P Internet Protocol (PIP)
The Simple Internet Protocol (SIP)
TP/IX
Em Novembro (1992), no seio da IETF, decorreu uma sessão denominada Selection
Criteria BOF com o objectivo de obter consenso em relação ao critério a aplicar na
escolha do sucessor do protocolo IPv4. Dos dois documentos preparatórios em discussão
e dos pontos de vista expressos na reunião saiu um novo documento contendo os
critérios de selecção tidos como consensuais.
Dispondo da sugestão do Internet Engineering Steering Group (IESG) em relação ao
critério técnico a adoptar na escolha do próximo protocolo IP delineada no RFC 138011 e
dos resultados da discussão dentro do próprio IETF anteriormente referida, e o IETF
considerou necessário um debate alargado sobre este tópico e emitiu um ―call for white
paper‖. [2]
Em resposta a esta solicitação foram recebidos vinte e três artigos contendo os pontos de
vista dos sectores industrial, tecnológico e comercial.
1993 - Phil Gross (IESG) apresenta um memorando intitulado "A Direction for IPng" onde
anuncia a criação de uma área temporária para o IPng. CLNP e IP Encaps evoluem,
dando origem respectivamente a TCP and UDP with Bigger Addresses, TUBA e IPAE.
1993 (finais) – SIP evoluiu, abrangendo características do IP Address Encapsulation
(IPAE)12. SIP e PIP deram origem à proposta The Simple Internet Protocol Plus (SIPP).
Ao mesmo tempo, a proposta TUBA alterou o nome para Common Architecture for the
Internet (CATNIP).
1994 - Aprovação do documento The Recommendation for the IP Next Generation
Protocol13 como norma oficial de desenvolvimento do IPng.
1995 – Foi publicado o primeiro conjunto de RFC’s especificando o IPv6 [RFC 1883]14
11
IESG Deliberations on Routing and Addressing http://www.rfc-editor.org/in-notes/rfc1380.txt 12
O IPAE foi adoptado como estratégia de transição para o SIP (Simple IP), proposto por Steve Deering em Novembro de 1992 http://tools.ietf.org/html/draft-ietf-ipae-ipv7-criterias-00 13
The Recommendation for the IP Next Generation Protocol http://www.ietf.org/rfc/rfc1752.txt
Capítulo II – IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 21
1995 – Concepção do Projecto 6Bone
1996 (Março) – Formalização do projecto 6bone em Março, no encontro IETF em Los
Angeles.
1996 (Junho) – Início da rede 6bone, através da criação de dois túneis: um entre a
Universidade de Lisboa (UL/PT), o Navy Research Laboratory15 (NRL/US) e a CISCO16
(CISCO/US) e o outro entre a UNI-C (UNIC/DK), o grupo G6 do instituto de pesquisa
IMAG (G6/FR) e o grupo WIDE, do Japão (WIDE/JP).
1996 (Dezembro) – Formação do grupo de trabalho 6bone (actualmente NGtrans).
1997 (Agosto) – No encontro do grupo de trabalho ngtrans-6bone que decorreu em
Munique, referiu-se que existiam mais de 150 sites IPv6 em 28 países participantes na
6bone. O protocolo de encaminhamento do backbone da 6bone passou a ser o BGP4+.
Foi criado o domínio 6bone.net, através do qual se pode aceder às páginas e base de
dados 6bone.
1997 (Dezembro) – No encontro de Washington, a 6bone apresentava já 206 sites em 30
países participantes.
1998 (Março) – No encontro de Los Angeles, a 6bone apresentava 240 sites IPv6 em 32
países.
2010 (Setembro) – Segundo estimativas actuais de Geoff Houston17, conceituado
responsável da APNIC, os endereços IPv4 ficarão completamente esgotados em Janeiro
de 2012.
2011 (Janeiro) - A Internet Assigned Numbers Authority (IANA) entregou dois dos últimos
sete blocos de endereços Internet em IPv4. Tudo indica que os últimos cinco blocos são
entregues em breve. O esgotamento de endereços está iminente.
14
Internet Protocol, Version 6 (IPv6) http://www.ietf.org/rfc/rfc1883.txt 15
Naval Research Laboratory http://www.nrl.navy.mil/ 16
Cisco http://www.cisco.com/ 17
Geoff Houston – ―Potaroo‖ IPv4 Address Report http://www.potaroo.net/tools/ipv4/
Capítulo II – IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 22
1.3. Porquê o IPv6?
Segundo a Internet Corporation for Assigned Names and Numbers (ICANN18), a
inovação e o crescimento contínuo da Internet, trazem novos desafios que mantém a
estabilidade. Na concepção do protocolo IP, há aproximadamente duas décadas, não
foram previstas necessidades emergentes da sociedade e da sua relação com os
sistemas de comunicação actuais, em particular com a Internet. Devido a este facto, há
características que necessitam de alterações.
Essas características necessárias são espaços de endereçamento, auto-configuração,
mobilidade, segurança na camada da rede, qualidade de serviço e suporte de aplicações
no tempo real.
Tal como qualquer versão superior, o IPv6 baseia-se essencialmente na resolução
de antigos problemas e implementação de novas funcionalidades. Isso não quer dizer
que o protocolo IPv4 esteja mal implementado, muito pelo contrário. O IPv4, especificado
desde 1981, obteve um grande sucesso e continua a tê-lo, por isso mesmo se adivinha
ainda difícil a curto prazo, a tarefa da sua substituição pelo IPv6.
O IPv6 é um pouco controverso no que diz respeito à sua necessidade actual. Opções a
curto prazo têm sido escolhidas em detrimento do IPv6, mas o desenvolvimento dessas
estratégias tende a tornar-se desmotivador.
A nova versão do protocolo não é uma necessidade urgente, como o mediático bug do
ano 2000. O IPv6 implicará uma movimentação bem mais vagarosa por parte do mundo
empresarial, ao contrário do que aconteceu com o bug. Mas esta necessidade é real e a
força que mais o impulsiona é o rápido crescimento da Internet. [3]
A motivação primária para mudanças no IP advém do espaço de endereçamento
limitado. Quando o IP foi definido, existiam somente algumas redes. Foi usado 32 bits
para o endereçamento IP, o que permitiria que a internet incluísse mais de um milhão de
redes. Porém, a internet está crescendo exponencialmente, com o seu tamanho
duplicando em menos de um ano. Na taxa de crescimento actual, cada um dos actuais
prefixos de rede possível serão logo atribuídos, e nenhum crescimento adicional será
possível. Deste modo, a motivação primária para definir uma nova versão do IP surgiu da
limitação de espaço de endereçamento – são necessários endereços maiores para
acomodar o crescimento contínuo da internet. [4]
18
ICANN (acrónimo em inglês para Corporação da Internet para Atribuição de Nomes e Números)
http://www.icann.org/
Capítulo II – IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 23
As motivações primárias e secundárias para mudanças no IP surgiram das novas
aplicações e serviços existentes na internet. Por exemplo aplicações que disponibilizam
áudio e vídeo precisam entregar os dados em intervalos regulares. Para manter tais
informações cruzando a internet sem interrupções, o IP deve evitar variar frequentemente
as rotas. Embora o actual cabeçalho do pacote IP inclua um campo que pode ser usado
para solicitar um tipo serviço, o protocolo não define um tipo de serviço que pode ser
usado para entregar em tempo real de áudio e vídeo. [4]
Outras causas para mudanças no IP baseiam-se nas especificações do protocolo IPv6
que são mais claras e optimizadas, eliminando as características não utilizadas e
obsoletas do protocolo anterior (IPv4) atingindo assim uma optimização do protocolo IP.
Especificações essas que podem definir-se sucintamente como:
Protocolo auto-configurável.
Protocolo mais seguro.
Protocolo com mais responsabilidade a nível de QoS.
Protocolo com vista à mobilidade.
Protocolo mais eficiente.
Protocolo virado para o modelo ponto-a-ponto.
Mecanismos de transição entre os dois protocolos.
1.4. Limitações do IPv4
Não houve mudanças expressivas no protocolo IPv4 desde o RFC 791, publicada
em 1981. O protocolo IPv4 provou ser robusto e facilmente implementável, conseguindo
sustentar uma rede informática (ARPANET) que inicialmente foi pensada apenas para
fins militares e académicos nos Estados Unidos tendo-se depois expandido globalmente
para os dias de hoje ficando conhecida como a Internet. [5]
A internet prosperou de um protótipo de pesquisa para um sistema global de
comunicação. Contudo, o seu tamanho não é tão surpreendente como é a sua taxa de
crescimento. A figura 219 ilustra esse crescimento. A figura contém um gráfico com o
número de computadores ligados à internet em função do ano (1995 a 2010).
19
Estatísticas sobre o crescimento da internet:
Capítulo II – IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 24
Figura 2 - Crescimento da internet20
No ano de 1994 a Internet era composta por cerca de 40 mil redes. Em 1996 já eram 100
mil redes e a taxa de crescimento parecia duplicar o número de redes a cada ano. Hoje o
crescimento da Internet é independente das Universidades ou dos Centros de Pesquisa.
Existe uma forte massificação das sociedades em torno das questões relacionadas com a
sociedade da informação.
O tamanho do endereço de 32 bits faz com que o protocolo IPv4 seja um recurso com um
limite relativamente baixo. Mesmo assim, a alocação dos endereços IP's em boa parte
das vezes é mal feita.
O desenho inicial do protocolo IPv4 não antecipou os seguintes pontos:
Escassez de endereços devido ao crescimento exponencial da internet (China e
Índia).
http://www.internetworldstats.com/emarketing.htm
20 Crescimento da internet, medido pelo número de computadores ligados a cada ano.
Capítulo II – IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 25
Necessidade de simplificar e automatizar a configuração de redes devido ao
aumento de computadores e dispositivos que utilizam endereços IP.
Falta de suporte para serviços e aplicações emergentes. Estes novos serviços e
aplicações são mais exigentes e requerem garantia de entrega de pacotes de
dados em tempo real, garantia de disponibilidade e segurança da largura de
banda. [6]
A necessidade de segurança na Internet.
Necessidade de melhorar o suporte de entrega de pacotes de dados em tempo
real – denominado QoS (Quality of Service).
Devido ao problema da exaustão da capacidade de endereçamento e outras
limitações do IPv4, foram desenvolvidas e aplicadas soluções a curto prazo tais como: [7]
Atribuição de endereços que permitam atribuir várias classes C a organizações
que necessitem de mais do que 256 endereços mas para as quais uma classe B
seja excessiva;
Classless Inter-Domain Routing CIDR21 é mais um "balão de ar" do que
propriamente uma solução, pois permite apenas adiar, por mais algum tempo, a
data de exaustão do espaço de endereçamento. [8]
O problema do tamanho excessivo das tabelas de encaminhamento foi parcialmente
contornado com a adopção do Classless InterDomain Routing (CIDR) descrito pelo RFC
4632. [9]
A ideia básica do CIDR é alocar as redes de classe C restantes (cerca de 2 milhões) em
blocos de tamanho variável. Se um site precisa de, por exemplo, 2000 endereços,
receberia 8 classes C contínuas que representam 2048 endereços.
Além disso, o RFC 4632 apontou novas regras para a alocação de redes de classe C
baseada na sua localização geográfica. O mundo foi dividido em 4 grandes zonas:
Europa, América do Norte, América Central e do Sul, Ásia e Pacífico. Assim sendo, cada
uma destas zonas teriam 32 milhões de endereços para serem alocados e outros 320
milhões de endereços classes C de 204.0.0.0 a 223.255.255.255. Com a solução CIDR,
21
Classless Inter-domain Routing http://www.rfc-editor.org/rfc/rfc4632.txt
Capítulo II – IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 26
as antigas classes A, B e C não são mais usadas para encaminhamento. A compreensão
de como se comportou o crescimento passado pode contribuir em muito na projecção de
um protocolo que tenha uma vida útil maior.
Network Address Translation (NAT) para contornar a falta de endereços IP. O
NAT mapeia múltiplos endereços IP privados para um único endereço IP público.
Possibilita a reutilização do espaço de endereçamento IP privado, mas não
suporta padrões base de segurança ao nível da camada de rede nem o correcto
mapeamento de todas as camadas protocolares acima dessa camada. Este
mecanismo, apesar de parecer à primeira vista perfeito, também pode criar
problemas quando duas organizações estão conectadas e utilizam um espaço de
endereçamento IP privado. Para além disso, o crescimento dos dispositivos e
aplicações ligados à Internet provam que o espaço de endereçamento IP público
irá acabar.
1.5. Especificação do IPv6
O IPv6 contém muitas das características que fizeram o IPv4 ser tão bem sucedido.
Apesar de reter os conceitos básicos do IPv4, o IPv6 modifica todos os detalhes. As
funcionalidades do IPv4 que não têm um bom desempenho ou que não são usadas com
frequência foram removidas ou tornadas opcionais. Certas capacidades novas que se
consideram necessárias foram adicionadas sem, no entanto, alterar os conceitos do IPv4.
[4]
As principais alterações efectuadas do IPv4 para o IPv6 podem ser agrupadas na
seguinte categoria: [10]
Extensão das capacidades de endereçamento e encaminhamento – O tamanho
de endereços passa de 32 bits na versão 4 para 128 bits na versão 6, o que
permite o suporte de um número muito superior de nós, uma melhor
hierarquização do espaço de endereçamento essencial à escalabilidade do
encaminhamento e uma maior facilidade em termos de auto configuração. A
escalabilidade dos endereços Multicast é também aumentada através da adição
do campo ―scope‖. E também é definido novo tipo de endereço designado
―anycast‖ usado para enviar um pacote para qualquer um dos grupos de nós.
Simplificação do formato do cabeçalho – Alguns campos do cabeçalho IPv4 foram
removidos ou passaram a ser opcionais de forma a simplificar o tratamento de um
Capítulo II – IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 27
pacote comum. O cabeçalho IPv6 tem um comprimento fixo de 40 bytes, em vez
dos variáveis 20 bytes do IPv4.
Suporte para cabeçalho de Extensão e de opções – Mudanças na forma como as
opções do cabeçalho IP são codificados permitem um encaminhamento mais
eficaz. Este suporte permite também que outras opções futuras possam vir a ser
incorporadas dando assim maior flexibilidade.
Capacidade de Flow Labeling – É adicionada uma nova funcionalidade para
identificar fluxos com necessidade de tratamento idêntico, sendo o fluxo
identificado pelo Flow Label e pelo endereço de origem. Esta identificação é feita
recorrendo apenas ao campo Flow Label ao endereço de origem, sem ter de
recorrer á análise profunda dos pacotes.
Suporte para autenticação e privacidade – Foram incluídas novas extensões ao
protocolo que oferecem suporte para autenticação, integridade de dados e
confidencialidade.
Suporte de auto-configuração – Foram incluídos mecanismos destinados a gestão
e configuração de ambientes IP através da utilização de mecanismos de auto-
configuração. Foram definidos mecanismos de auto-configuração com
manutenção de estados e mecanismos sem manutenção de estados.
Suporte para tráfego com garantia de qualidade de serviço;
Suporte para Jumbograms – Possibilidade de enviar pacotes com dimensão
superior a 64Kb. O limite de um pacote Jumbogram é de 4Gb. Esta propriedade é
útil para as redes com grande largura de banda.
Mapeamento de endereços e Nomes;
Encaminhamento
Capítulo II – IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 28
Simplificação do cabeçalho
O cabeçalho IPv6 foi simplificado em relação ao cabeçalho IPv4 no que se refere
aos campos de controlo, porém o seu tamanho passou de 20 a 40 bytes fixos para
qualquer tipo e tamanho de datagrama. Esta alteração deve-se ao facto do tamanho do
endereço passar de 4 para 16 octetos.
Um cabeçalho básico IPv6 contém menos informações do que um cabeçalho IPv4.
Alguns campos do cabeçalho IPv4 foram retirados ou passaram a ser opcionais de forma
a simplificar o tratamento de um pacote comum. Embora os endereços IPv6 sejam 4
vezes maiores que os endereços IPv4, o cabeçalho é apenas duas vezes maior (40
bytes).
Figura 3 - Cabeçalho IPv422
.
Figura 4 - Cabeçalho IPv623
.
22
Figura retirada do RFC 791: http://www.faqs.org/rfcs/rfc791.html 23
Figura retirada da Secção 3 - IPv6 Header Format do RFC 2460: http://tools.ietf.org/html/rfc2460#section-4
Capítulo II – IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 29
Simplificações (Campos Removidos):
Campo IHL – A remoção do campo IHL (Internet Header Length) advém do facto
de este campo essencialmente especificar o offset para a porção de dados do
cabeçalho IP. Este conceito, que obrigava a uma informação adicional acerca do
endereço dos dados, foi removido no IPv6.
Campos Identification, Flags e Fragment Offset – Estes três campos são
referentes ao processo de fragmentação que poderá ser necessário utilizar ao
longo de todo o caminho do pacote. São campos de controlo e identificação dos
fragmentos. A fragmentação no IPv6 é feita usando os Cabeçalhos de Extensão e
é feito extremo a extremo, isto é, a fragmentação apenas é efectuada na origem,
usando o protocolo PMTU [11] libertando os routers dessa tarefa, onde descartam
todos os pacotes maiores que o MTU da rede. Isso faz com que não seja
desperdiçado processamento em campos desnecessários quando não ocorre
fragmentação.
Campo Header Checksum – Este campo serve para verificação de erros apenas
no cabeçalho IP. Foi removido devido a um conjunto de situações:
Geralmente os pacotes são corrompidos na camada 2 (Data Link), e essa camada
tem geralmente melhores mecanismos para detecção de erros;
Se mesmo assim existir algum problema, a camada acima poderá solucionar esse
problema.
Se o pacote estiver corrompido, então o nó destino deverá estar preparado para o
recusar, apesar de algum impacto a nível de processamento;
Os meios de transmissão existentes (fibra óptica) são mais fiáveis a assegurar
uma comunicação com menos falhas.
O campo Header Checksum tinha de ser recalculado em cada nó devido à
alteração do campo Hop Limit sobrecarregando os routers.
Campos Options e Padding - O campo Padding serve para completar o pacote
(tamanho múltiplo de 32 bits). Em relação ao campo Options, tem alguma
utilidade a nível de encaminhamento, mas raramente é utilizado. O IPv6 junta um
pouco a funcionalidade deste campo à do campo Protocol e utiliza-os no conceito
dos Cabeçalhos de Extensão. De certa forma algumas funcionalidades do campo
Capítulo II – IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 30
Options são passadas para os Cabeçalhos de Extensão. O campo Protocol é
substituído pelo Next Header, parecido com o campo Protocol do IPv4, que
interliga todos os cabeçalhos de Extensão.
Campos revistos:
Substituição do campo Type of Service – Este campo era o responsável por
algum QoS que pudesse existir no IPv4, no entanto nunca foi adoptado pelos
routers, principalmente por ser muito pequeno. No IPv6 o QoS divide-se em dois
campos: o campo Traffic Class e o campo Flow Label; o primeiro é direccionado
ao catálogo de tráfego (DiffServ) e o segundo à geração de fluxos prioritários
(IntServ).
Substituição do campo Total Length – Este campo indica o tamanho total do
pacote, incluindo os dados. Foi substituído pelo campo Payload Length que
representa o tamanho do resto do pacote que se segue ao cabeçalho IPv6, ou
seja, o tamanho do cabeçalho IPv6 não é neste caso necessário, pois o
cabeçalho tem tamanho fixo.
Substituição do campo Time to Live – A substituição desde campo é devido a
questões de interpretação. Ao contrário do que o nome indica, este campo é
medido em saltos e não em tempo, pelo que a designação Hop Limit vem corrigir
esta pequena confusão. Nada como ter o nome correspondente à função que
desempenha.
Substituição do campo Protocol – Apesar de o nome ser diferente, o novo
campo Next Header funciona de uma forma semelhante ao campo Protocol. No
IPv4 indicava o protocolo da camada acima que ia ser encapsulado. No IPv6
indica o protocolo de camada superior ou o Cabeçalho de Extensão seguinte. É
como que um campo que interliga todos os Cabeçalhos de Extensão. Quando não
se verificarem mais Cabeçalhos de Extensão, então indicará o protocolo da
camada acima correspondente, tal como o campo Protocol.
Alteração dos campos Source Address e Destination Address – Esta
alteração é a mais evidente e consiste na passagem dos endereços de 32 bits
para 128 bits. Verifica-se então, nas alterações efectuadas, uma maior
preocupação em relação a questões como a eficiência e a simplicidade. Eficiência
na medida em que só é processado aquilo que é realmente obrigatório.
Exploração da Implementação actual de IPv6 no Kernel do Linux 31
Capítulo III
Ferramenta de conformidade da especificação IPv6
1.1. Considerações Gerais
Para a realização dos testes de conformidade do IPv6, será utilizado uma ferramenta
de teste designado por TAHI IPv6 Suite teste de conformidade, desenvolvida pelo
projecto TAHI com a finalidade de desenvolver e fornecer mecanismos que permitam
verificar a conformidade da tecnologia IPv6 em relação aos RFC´s.
Esta ferramenta consiste em duas componentes, numa plataforma de teste e num
conjunto de scripts de teste. Sendo a plataforma de teste designada por ferramenta de
teste de conformidade IPv6 (―IPv6 Conformance Test Tool‖) e o script de testes
designado por Pacote de Programa de teste de conformidade do IPv6 (―IPv6
Conformance Test Program Package‖)
O IPv6 Conformance Test Tool (v6eval) é um pacote de ferramentas que permite a
execução de testes de conformidade para o IPv6. Essas ferramentas permitem:
Definir qualquer pacote a ser enviado;
Definir qualquer pacote a ser recebido;
Programar as acções anteriores em qualquer ordem usando scripts Perl.
IPv6 Conformance Test Program Package (ct) é um conjunto de scripts contendo
testes de conformidade IPv6 em relação a grande parte dos RFC´s IPv6 existentes.
Capítulo III – Ferramenta de conformidade da especificação IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 32
Na tabela seguinte serão listados alguns scripts contendo um conjunto de testes
disponíveis por categoria.
Nome Categoria do teste
Spec RFC2460: Especificação do IPv6
Icmp RFC2463: ICMPv6 para o IPv6
Nd RFC2461: Descobrimentos de vizinhos (Neighbor Discovery)
Pmtu RFC1981: Path MTU Discovery for IPv6
IPsec RFC2401: Security Architecture for the IP
Tabela 1 - Script de teste disponível
Ambos os pacotes ―ct‖ e ―v6eval‖ podem ser obtidos do site: http://www.tahi.org
Para a realização dos testes de conformidade, serão utilizadas algumas distribuições
Linux: FreeBSD, Ubuntu e Centos. Em que a distribuição FreeBSD será utilizada como
o nó de teste e será designado por TN, e as outras distribuições serão utilizadas como
nós em teste e serão designados por NUT. Onde o TN será o nó que realiza o teste e o
NUT será o nó testado.
O TN e o NUT terão um ficheiro de configuração designado respectivamente de tn.def e
nut.def. Nestes ficheiros encontram-se definidos configurações específicos referentes a
cada nó.
Os testes podem ser executados de forma manual recorrendo à linha de comando ou de
forma automática recorrendo a um programa de execução automática de testes
(autorun). Para a realização deste trabalho os testes serão executados de forma
automática recorrendo a um programa de execução automática de testes (autorun). A
execução automática dos testes consiste em enviar um conjunto de pacotes e verificar as
respostas. Os testes a serem realizados são especificados no ficheiro Index, e o
programa de teste ao executar os testes verifica o ficheiro de configuração do TN e do
NUT, e com base nesses ficheiros realiza os testes anteriormente especificados e os
resultados verificados serão listados num ficheiro HTML designado de ―./index.html‖,
como se ilustra na figura seguinte:
Capítulo III – Ferramenta de conformidade da especificação IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 33
IndexReport Index
(HTML)Autorun
Test scriptPacket.def
Exec with Option Status
Figura 5 - Programa de execução Automática
1.2. Procedimento comum de limpeza dos testes
A limpeza da cache de vizinhança (Neighbor Cache) do NUT (nó em teste) após cada
execução de um teste é um procedimento comum em todos os testes. Este procedimento
consiste na transição das entradas da cache de vizinhança do NUT criada durante a
execução do teste para o estado NO Neighbor Cache Entry e a remoção de qualquer
entrada do router por defeito e a também da lista de prefixo no caso do NUT ser um
router.
1.3. Definição da estrutura do pacote
O pacote a ser enviado/recebido é criado usando a API Perl, através da definição de
cada um dos seus componentes:
Frame – composto pelos seguintes elementos (Header, Packet);
Pacote – pacote_IPv6, pacote_IPv4, pacote_ARP, pacote_RARP;
Payload – dados.
Ao executar o teste de conformidade automaticamente, as seguintes regras se aplicam
aos nomes de arquivo de scripts.
A extensão é ". seq".
Capítulo III – Ferramenta de conformidade da especificação IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 34
Os scripts de teste encontram-se definidos dentro das directorias utilizados para
classificar os arquivos de acordo com o RFC, não sendo necessário a definição
manual dos pacotes a ser enviado.
A tabela seguinte lista os valores possíveis de retorno da execução dos scripts de teste.
Código Constante Descrição
0 $exitPass PASS
1 $exitIgnore Terminação normal
2 $exitNS Ainda não suportado
3 $exitWarn Não pode ser identificado como uma falha porque a especificação não é clara
4 $exitHostOnly Teste suportado apenas por host
5 $exitRouterOnly Teste suportado apenas por router
32 $exitFail Fail
64 $exitFatal Erro interno
Tabela 2 - Script Status Code
1.4. Exemplos de Funções Disponíveis na API
Existem disponível um conjunto de funções:
Funções Disponíveis na API
vStop()
vClear()
vCapture()
vSend()
vRecv()
vLog ()
vRemote ()
vErrmsg ()
vRoundoff ()
vSleep ()
Tabela 3 - Funções disponíveis na API
Capítulo III – Ferramenta de conformidade da especificação IPv6
Exploração da Implementação actual de IPv6 no Kernel do Linux 35
Na tabela seguinte serão exemplificadas a algumas das funções definidas anteriormente
vSend ()
Descrição Permite especificar um pacote a ser enviado para a interface especificada.
Argumento sub vSend($@) {my (
$ ifname, # nome da interface do target
@ Frames, # nome pacote a ser enviado
) = @_;
Valor de retorno
É retornado um valor de hash. A key e o valor é o seguinte: SentTimeN
Tabela 4 - Exemplo vSend
vRecv
Descrição O teste é realizado para determinar quando é que um determinado pacote pode ser recebido da interface especificada
Argumento sub vRec($$$$@) {my (
$ ifname, # nome da interface do target
$ timeout,
$ seektime, # procurar pelo pacote a partir do tempo
$ count, # esperar por quantas frames
@ Frames, # nome da frame a ser enviado
) = @_;
Valor de retorno
É retornado um valor de hash. A key e o valor é o seguinte: = 0 – Terminação normal = 1 – Terminação com Timeout = 2 – o pacote especificado foi recebido, mas o pacote esperado
não foi recebido >=3 – erro
Tabela 5 - Exemplo vRec
Exploração da Implementação actual de IPv6 no Kernel do Linux 36
Capítulo IV
Descrição dos testes IPv6 realizados
1. Considerações Gerais
Os testes realizados neste capítulo abrangem a especificação base do IPv6,
definidos no RFC 2460, bem como o processamento das Opções e Cabeçalhos de
Extensões, em particular o Hop-by-Hop Option, Destination Option.
São especificados o cabeçalho IPv6 e os cabeçalhos de Extensão e Opções. Também
serão abordados questões relacionados com o tamanho do pacote, a semântica do Flow
Label e Traffic Classes.
Em relação à especificação base do IPv6 estes testes têm a finalidade de verificar
a disponibilidade da implementação do IPv6, onde serão verificados se o nó em teste
(NUT) processa correctamente os campos: Version, Traffic Class, Flow Label, Payload
Length, Next Header e Hop Limit. Também será verificado se o nó em teste (NUT)
transmite a mensagem ICMPv6 apropriada em resposta à recepção de um campo
inválido ou desconhecido.
Em relação ao processamento das Opções e Cabeçalhos de Extensões, em
particular o Hop-by-Hop Option, Destination Option os testes realizados têm a finalidade
de verificar se o nó em teste (NUT) processa e gera correctamente o campo Header
Extension Length do Cabeçalho de Extensão, os campos Option Type e Option Data
Length do campo Option. Será igualmente, verificado o nó em teste (NUT) se envia a
mensagem ICMPv6 apropriada em resposta ao envio de pacotes, com campos inválidos
ou desconhecidos.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 37
2. Testes em relação à especificação base do IPv6
2.1. Teste ao Campo Versão (Version Field)
O campo Versão tem 4 bits que indicam a versão do protocolo. No caso do IPv6 é o
número 6. A versão 5 não poderia ser usada porque já havia sido atribuída para um
protocolo experimental.
2.1.1. Objectivo
O objectivo deste teste consiste em verificar se o nó em teste (NUT) processa
correctamente o campo Versão (Version) de um pacote recebido.
2.1.2. Corpo do Teste
O nó de teste (TN) envia dois pacotes Echo Request para o nó em teste (NUT),
em que o primeiro pacote contém o campo versão inválido (campo versão igual a 5) e o
segundo pacote um pacote valido contendo o campo versão igual a 6.
Para a realização do teste o programa de execução automática utilizou o script
IH_BadIPv6Ver.seq onde se encontram definidos funções que permitem gerar pacotes
Echo Request validos/inválidos.
Na tabela seguinte encontram-se listadas as funções usadas para gerar os dois pacotes
Echo Request.
Funções definidas no script IH_BadIPv6Ver.seq
Echo Request inválido FEM_icmp6_echo_request(
echo_request_wrong_v6ver,
_HETHER_tn2nut,
{Version=5;},
{
Identifier = PING_ID;
SequenceNumber = PING_SN;
payload = echo_data8;
}
)
Echo Request válido FEM_icmp6_echo_request(
echo_request,
_HETHER_tn2nut,
{},
{
Identifier = PING_ID;
SequenceNumber = PING_SN;
payload = echo_data8;
}
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 38
)
Neighbor Solicitation FEM_icmp6_ns(
ns,
_HETHER_nut2tnsolnode,
{
_SRC(oneof(nutv6(),
nut2v6(_GLOBAL0_UCAST_PRFX,
_GLOBAL0_UCAST_PRFXLEN)));
_DST(_IPV6_SOLNODE_MCAST(tnv6()));
HopLimit = 255;
},
{
TargetAddress = tnv6();
option = _SLLOPT_nut;
}
)
Tabela 6 – Funções do script IH_BadIPv6Ver.seq
Na tabela seguinte encontram-se listados as estruturas dos pacotes gerados pelas
funções anteriores.
Send Echo Request (but invalid version)
Frame_Ether (length:70) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:56) | | Hdr_IPv6 (length:40) | | | Version = 5 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 16 | | | NextHeader = 58 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | ICMPv6_EchoRequest (length:16) | | | Type = 128 | | | Code = 0 | | | Checksum = 37888 calc(37888) | | | Identifier = 65535 | | | SequenceNumber = 1 | | | Payload (length:8) | | | | data = 01020304 05060708
Send Echo Request
Frame_Ether (length:70) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:56) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 16 | | | NextHeader = 58 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | ICMPv6_EchoRequest (length:16) | | | Type = 128 | | | Code = 0 | | | Checksum = 37888 calc(37888) | | | Identifier = 65535 | | | SequenceNumber = 1 | | | Payload (length:8) | | | | data = 01020304 05060708
Neighbor Solicitation
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 39
Frame_Ether (length:86) | Hdr_Ether (length:14) | | DestinationAddress = 33:33:ff:00:01:00 | | SourceAddress = 00:0c:29:1f:b2:72 | | Type = 34525 | Packet_IPv6 (length:72) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 32 | | | NextHeader = 58 | | | HopLimit = 255 | | | SourceAddress = fe80::20c:29ff:fe1f:b272 | | | DestinationAddress = ff02::1:ff00:100 | | ICMPv6_NS (length:32) | | | Type = 135 | | | Code = 0 | | | Checksum = 49505 calc(49505) | | | Reserved = 0 | | | TargetAddress = fe80::200:ff:fe00:100 | | | Opt_ICMPv6_SLL (length:8) | | | | Type = 1 | | | | Length = 1 | | | | LinkLayerAddress = 00:0c:29:1f:b2:72
Tabela 7 - Pacotes gerados pelo script IH_BadIPv6Ver.seq
As sequências de acções executadas pelo programa de execução automática no
decorrer do teste ao campo versão encontram-se listadas na tabela seguinte:
Nº Sequências de acções realizados pelo Conformance Tool
Descrição
1 Start
2 Start Capturing Packets (Link0)
3 vSend(Link0,echo_request_wrong_v6ver) Envio do pacote Echo Request com o
campo versão inválido
4 vRecv(Link0,) timeout:5 cntLimit:0 seektime:0
vRecv() return status=1
Não recebe nenhum Echo Replay a acção vRecv retorna o status 1 que é o valor correspondente ao Timeout
5 vSend(Link0,echo_request)
Send Echo Request
Envio do pacote Echo Request com o
campo versão válido
6 vRecv(Link0,ns echo_reply) timeout:5 cntLimit:0 seektime:0
Recv Neighbor Solicitation
Recebe o Neighbor Solicitation enviado
pelo NUT
7 vSend(Link0,na)
Send Neighbr Advertisement
Envio do Neighbor Advertisement
8 vRecv(Link0,echo_reply) timeout:5 cntLimit:0 seektime:0
Recv Echo Reply (Link-Local Address)
Recebe o Echo Replay
9 OK
10 End
Tabela 8 - Acções executadas no teste ao campo Versão
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 40
Na acção nº 7 o NUT envia um Neighbor Solicitation após o envio do Echo Request
valido uma vez que no final do teste anterior foi executado o procedimento comum de
limpeza o que fez com que a cache de vizinhança do NUT fosse limpa.
2.1.3. Resultado esperado do Teste
O NUT deve ignorar o Echo Request inválido, não gerando nenhuma mensagem
pacote inválido e deve apenas responder com Echo Replay ao Echo Request válido.
2.2. Teste ao campo Traffic Class
O campo Traffic Class tem 8 bits e substitui o campo tipo de serviço em IPv4.
Facilita a manipulação de dados em tempo real e de todos os outros dados que requerem
uma manipulação especial. Os nós que originam um pacote devem identificar diferentes
classes ou prioridades de pacotes IPv6, usando o campo Traffic Class do cabeçalho IPv6
para fazer essa identificação. Este campo também é usado pelos routers para identificar
e distinguir entre classes ou prioridades diferentes dos pacotes IPv6.
Os seguintes requisitos gerais que se aplicam ao campo Traffic Class: [10]
A interface usada pelo nó IPv6 deve fornecer o valor dos bits Traffic Class
para o protocolo de camada superior. Os bits Traffic Class devem constar
nos pacotes originados pelo protocolo da camada superior. O valor por
defeito deve ser zero para todos os 8 bits.
Nós que suportam alguns dos bits Traffic Class ou todos podem alterar o
valor desses bits. Podendo apenas alterar os valores dos pacotes que
originam, enviam ou recebem de acordo com o uso específico desses bits.
Os nós devem ignorar e não alterar qualquer bit do campo Traffic Class
que não suportam o seu uso.
O valor dos bits do campo Traffic Class de um pacote recebido pode não
ser igual ao valor enviado pelo emissor. Logo um protocolo da camada
superior não deve assumir que o valor dos bits do campo Traffic Class de
um pacote recebido
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 41
2.2.1. Objectivo
O objectivo deste teste consiste em verificar se o NUT processa correctamente o
campo Traffic Class de um pacote recebido e gera um valor válido no pacote transmitido.
2.2.2. Corpo do Teste
O nó de teste (TN) envia um pacote Echo Request para o nó em teste (NUT), com
o valor do campo Traffic Class igual a 0x12 (formato hexadecimal), que equivale a 18
(formato decimal), que é diferente de zero.
Para a realização do teste o programa de execução automática utilizou o script
TC_NonZeroToHost.seq onde se encontram definidas algumas funções entre elas uma
que permite gerar um pacote Echo Request com o campo Traffic Class diferente de zero.
Na tabela seguinte encontra-se listada a função descrita anteriormente.
Funções definidas no script TC_NonZeroToHost.seq
Echo Request com campo Traffic Class diferente de zero
FEM_icmp6_echo_request(
echo_request,
_HETHER_tn2nut,
{
_SRC(tnv6());
_DST(nutv6());
TrafficClass = 0x12;
},
{
payload = echo_data8;
}
)
Tabela 9 - Função do script TC_NonZeroToHost.seq
O pacote Echo Request gerado pela função ―FEM_icmpv6_echo_request(…)‖ definido
no script ―TC_NonZeroToHost.seq‖ é semelhante ao pacote gerado pelo script
―IH_BadIPv6Ver.seq‖ ilustrado na tabela 6, com a diferença no valor do campo Traffic
Class que é igual a 18.
As sequências de acções executadas pelo programa de execução automática no
decorrer do teste ao campo Traffic Class encontram-se listadas na tabela seguinte:
Nº Sequências de acções realizados pelo Conformance Tool
1 Start
2 Start Capturing Packets (Link0)
3 vSend(Link0,echo_request)
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 42
Send Echo Request (Non-Zero Traffic Class)
4 vRecv(Link0,ns echo_reply_tc echo_reply) timeout:5 cntLimit:0 seektime:0 Recv Echo Reply (Zero Traffic Class)
5 OK
6 End
Tabela 10 - Acções executadas no teste ao campo Traffic Class
2.2.3. Resultado esperado do Teste
O NUT deve gerar um Echo Replay em resposta ao Echo Request recebido. Caso
o NUT suporte um uso específico do campo Traffic Class, o campo Traffic Class do Echo
Replay pode ser diferente de zero, caso contrário o campo Traffic Class deverá ser zero
2.3. Teste ao campo Flow Label
Campo que ocupa 20 bits no cabeçalho IPv6 e que permite a identificação de fluxos24
de pacotes. Por omissão o seu valor é zero (0), qualquer valor diferente de zero indicará
uma diferenciação de fluxo.
Este campo indica se um pacote pertence a uma sequência específica de pacotes entre a
origem e o destino, requerendo tratamento especial por parte dos routers IPv6
intermédios.
Podem existir múltiplos fluxos activos de uma origem para um destino, como também
pode existir tráfego que não é associado a qualquer fluxo. Um fluxo é exclusivamente
identificado pela combinação de um endereço de origem e uma etiqueta de fluxo não
nula. Pacotes que não pertencem a um fluxo contêm uma etiqueta de fluxo com valor
nulo.
Aos nós e routers que não suportam funções de Flow Label é exigido que preencham o
valor do campo Flow Label com zero (0) quando geram um pacote, ao reencaminhar um
pacote o valor do campo Flow Label deve ir inalterado e ao receber um pacote devem
ignorar o campo.
24
Sequência de pacotes enviados por um determinado emissor para um destino específico para o qual, o
originador deseja um tratamento especial por parte dos routers intervenientes no encaminhamento de pacotes.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 43
2.3.1. Objectivo
O objectivo deste teste consiste em verificar se o NUT processa correctamente o
campo Flow Label de um pacote recebido e gera um valor válido no pacote transmitido.
2.3.2. Corpo do Teste
O nó de teste (TN) envia um pacote Echo Request para o nó em teste (NUT), com
o valor do campo Flow Label igual a 0x34567 (formato hexadecimal), que equivale a
214375 (formato decimal).
Para a realização do teste o programa de execução automática utilizou o script
FL_NonZeroToHost.seq onde se encontram definidas funções que permitem gerar
pacotes Echo Request com o campo Flow Label diferente de zero. A função utlizada para
gerar o pacote Echo Request é semelhante à função descrita na tabela 8
(TC_NonZeroToHost.seq), com a diferença num dos parâmetros de entrada onde foi
substituído o parâmetro (Traffic Class = 0x12;) pelo (Flow Label = 0x34567;) como se
pode ver na tabela seguinte:
Funções definidas no script FL_NonZeroToHost.seq
Echo Request com campo Flow Label diferente de zero
FEM_icmp6_echo_request(
echo_request,
_HETHER_tn2nut,
{
_SRC(tnv6());
_DST(nutv6());
FlowLabel = 0x34567; // 20bit
},
{
payload = echo_data8;
}
)
Tabela 11 - Função do script FL_NonZeroToHost.seq
O pacote Echo Request gerado pela função ―FEM_icmpv6_echo_request(…)‖ definida
no script ―FL_NonZeroToHost.seq‖ é semelhante ao pacote gerado pelo script
―IH_BadIPv6Ver.seq‖ ilustrado na tabela 6, com a diferença no valor do campo Flow
Label que é igual a 0x34567.
As sequências de acções executadas pelo programa de execução automática no
decorrer do teste ao campo Flow Label encontram-se listadas na tabela seguinte:
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 44
Nº Sequências de acções realizados pelo Conformance Tool
1 Start
2 Start Capturing Packets (Link0)
3 vSend(Link0,echo_request)
Send Echo Request (Non-Zero Flow Label)
4 vRecv(Link0,ns echo_reply_fl echo_reply) timeout:5 cntLimit:0 seektime:0
Recv Echo Reply (Zero Flow Label)
5 OK
6 End
Tabela 12 - Acções executadas no teste ao campo Flow Label
2.3.3. Resultado do Teste
O NUT deve gerar um Echo Replay em resposta ao Echo Request recebido. Caso
o NUT suporte o uso do campo Flow Label, o campo Flow Label do Echo Replay pode
ser diferente de zero, caso contrário o campo Flow Label deverá ser zero.
2.4. Teste ao campo Payload Length
O campo Payload Length indica em bytes, o tamanho total do pacote IP excluindo o
cabeçalho, ou seja, representa o número de bytes que se seguem ao cabeçalho. O
tamanho máximo do pacote IP é de 65.535 bytes, para valores superiores, é atribuído o
valor 0 e a opção Jumbo payload é usada nas opções Hop-by-Hop do cabeçalho de
extensão.
2.4.1. Objectivo
O objectivo deste teste consiste em verificar se o NUT processa correctamente o
campo Payload Length de um pacote recebido.
2.4.2. Corpo do Teste
O nó de teste (TN) envia um pacote Echo Request para o nó em teste (NUT), com
o valor do campo Payload Length igual 15.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 45
Para a realização do teste o programa de execução automática utilizou o script
PL_OddToHost.seq onde se encontram definidas algumas funções entre elas uma que
permite gerar um pacote Echo Request com o campo Payload Length diferente de zero.
Na tabela seguinte encontra-se listada a função descrita anteriormente.
Funções definidas no script PL_OddToHost.seq
Echo Request com campo Payload Length diferente de zero
FEM_icmp6_echo_request(
echo_request,
_HETHER_tn2nut,
{
_SRC(tnv6());
_DST(nutv6());
},
{
Identifier = PING_ID;
SequenceNumber = PING_SN;
payload = echo_data7;
}
)
Tabela 13 - Função do script PL_OddToHost.seq
Na tabela seguinte encontra-se listado o pacote Echo Request gerado pela função
definida anteriormente.
Send Echo Request
Frame_Ether (length:69) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:55) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 15 | | | NextHeader = 58 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | ICMPv6_EchoRequest (length:15) | | | Type = 128 | | | Code = 0 | | | Checksum = 37897 calc(37897) | | | Identifier = 65535 | | | SequenceNumber = 1 | | | Payload (length:7) | | | | data = 01020304 050607
Tabela 14 - Pacote gerado pelo script PL_OddToHost.seq
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 46
As sequências de acções executadas pelo programa de execução automática no
decorrer do teste ao campo Payload Length encontram-se listadas na tabela seguinte:
Nº Sequências de acções realizados pelo Conformance Tool
1 Start
2 Start Capturing Packets (Link0)
3 vSend(Link0,echo_request)
Send Echo Request (Odd Payload Length)
4 vRecv(Link0,ns echo_reply) timeout:5 cntLimit:0 seektime:0
Recv Echo Reply (Odd Payload Length)
5 OK
6 End
Tabela 15 - Acções executadas no teste ao Campo Payload Length
2.4.3. Resultado esperado do Teste
O NUT deve gerar um Echo Replay em resposta ao Echo Request recebido.
2.5. Teste campo Next Header irreconhecível
O campo Next Header é um campo de 8 bits, que indica o tipo possível do
cabeçalho de extensão que segue o cabeçalho IPv6. Este campo indica quer o tipo do
primeiro cabeçalho de extensão (caso exista), quer o protocolo na camada acima PDU
(tais como TCP, UDP, ICMPv6). No caso de ser indicado o protocolo da camada acima
PDU, este campo usa os mesmos valores usados no campo do protocolo IPv4. Na tabela
seguinte estão listadas alguns dos valores possíveis que este campo pode assumir:
Valor Descrição
0 Num cabeçalho IPv4: reservado e não usado Num cabeçalho IPv6: a seguir vem um cabeçalho Hop-by-Hop Option
1 Internet Control Message Protocol ICMPv4
2 Internet Group Management Protocol IGMPv4
4 IP dentro de IP (encapsulamento)
6 TCP
8 Exterior Gateway Protocol (EGP)
9 IGP – qualquer Gateway interior privado (usado pela Cisco para IGRP)
17 UDP
41 IPv6
43 Cabeçalho de Routing
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 47
44 Cabeçalho de Fragmentação
50 Cabeçalho Encrypted Security Payload
51 Cabeçalho Authentication
58 ICMPv6
59 Não existe Next Header para IPv6
60 Cabeçalho Destination Options
134-254
Sem Atribuição
255 Reservado
Tabela 16 - Alguns valores25
possíveis que o campo Next Header pode assumir
O não processamento de um cabeçalho de Extensão por parte dum nó, por este não
conseguir identificar o valor do campo Next Header, implica descartar pacote e o envio de
uma mensagem de erro (ICMPv6) ao originador com o campo Code (código) a 1
("Unrecognized Next Header Type encountered") e o campo Pointer contendo o offset do
valor irreconhecível do pacote original.
2.5.1. Objectivo
O objectivo deste teste consiste em verificar o não processamento de um
cabeçalho de Extensão por parte do NUT, por este não conseguir identificar o valor no
campo Next Header do cabeçalho IPv6, e também verificar se o NUT gera a resposta
apropriada ao receber um pacote com o campo Next Header do cabeçalho IPv6
irreconhecível.
2.5.2. Corpo do Teste
O nó de teste (TN) envia um pacote com o valor do campo Next Header do
cabeçalho IPv6 irreconhecível.
Para a realização do teste o programa de execução automática utilizou o script
IH_UnrecognizedNextHeader.seq onde se encontram definidas algumas funções entre
elas uma que permite gerar um pacote com o valor do campo Next Header do cabeçalho
IPv6 irreconhecível.
25
A lista completa do Protocol Numbers encontra-se definida no site IANA: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 48
Na tabela seguinte encontra-se listada a função descrita anteriormente.
Funções definidas no script IH_UnrecognizedNextHeader.seq
FEM_hdr_ipv6_exth(
unrecog,
_HETHER_tn2nut,
{
_SRC(tnv6());
_DST(nutv6());
NextHeader = 128; //
unrecognized value
},
{
header = _HDR_IPV6_NAME(unrecog);
upper = apl;
}
) Tabela 17- Função do script IH_UnrecognizedNextHeader.seq
Na tabela seguinte encontram-se listadas as estruturas dos pacotes gerados pela função
anterior.
Pacote contendo o campo Next Header do cabeçalho IPv6 irreconhecível
Send Unrecognized Next Header in IPv6 Header at 21:33:36 Frame_Ether (length:64) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:50) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 10 | | | NextHeader = 128 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Payload (length:10) | | | data = 00000000 00000000 0000
Tabela 18 - Pacote gerado pelo script IH_UnrecognizedNextHeader.seq
As sequências de acções executadas pelo programa de execução automática no
decorrer do teste ao campo versão encontram-se listadas na tabela seguinte:
Nº Sequências de acções realizados pelo Conformance Tool
1 Start
2 Start Capturing Packets (Link0)
3 vSend(Link0,unrecog)
Send Unrecognized Next Header in IPv6 Header
4 vRecv(Link0,ns icmperr) timeout:5 cntLimit:0 seektime:0
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 49
Recv ICMP Error (Parameter Problem, unrecognized Next Header type encountered)
9 OK
10 End
Tabela 19 - Acções executadas no teste ao campo Next Header
2.5.3. Resultado esperado do Teste
O NUT ao receber um pacote com o valor do campo Next Header do cabeçalho IPv6
irreconhecível, deve gerar uma mensagem de erro ICMPv6 (Parameter Problem
message) com o valor do campo Code a 1 (Unrecognized Next Header Type
encountered) e com o campo Pointer a 0x06 (offset do campo Next Header).
2.6. Teste campo Hop Limit igual a zero
Campo que indica o número máximo de nós intermédios que um pacote pode
percorrer até alcançar o destino. Este campo é semelhante ao campo TTL, mas agora
com a medida em saltos (Hop) e não em segundos. Cada valor unitário do Hop Limit
significa uma passagem por um router, um salto. Sendo decrementado em cada salto, e
quando o pacote atinge o valor 0 é descartado pelo router que envia uma mensagem
ICMPv6 Time Exceeded-Hop Limit Exceeded in transit para o destino e descarta o pacote
2.6.1. Objectivo
Verificar se um nó processa correctamente o campo Hop Limit de um pacote
recebido e gera um valor válido no pacote transmitido.
2.6.2. Corpo do Teste
O nó de teste (TN) envia um pacote Echo Request para o nó em teste (NUT), com o valor
do campo Hop Limit igual zero e o NUT deve gerar o pacote Echo Replay correspondente
com o valor do campo Hop Limit diferente de zero (Hop Limit default 64).
Para a realização do teste o programa de execução automática utilizou o script
“HL_ZeroToHost.seq‖ onde se encontram definidas algumas funções, entre elas uma
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 50
que permite gerar pacotes Echo Request com o campo Hop Limit igual zero. A função
utlizada para gerar o pacote Echo Request é semelhante à função descrita na tabela 8
(TC_NonZeroToHost.seq), com a diferença num dos parâmetros de entrada onde foi
substituído o parâmetro (Traffic Class = 0x12;) pelo (Hop Limit = 0;) como se pode ver na
tabela seguinte:
Funções definidas no script HL_ZeroToHost.seq
Echo Request com campo Hop Limit diferente de zero
FEM_icmp6_echo_request(
echo_request,
_HETHER_tn2nut,
{
_SRC(tnv6());
_DST(nutv6());
HopLimit = 0;
},
{
payload = echo_data8;
}
)
Tabela 20 - Função do script HL_ZeroToHost.seq
O pacote Echo Request gerado pela função ―FEM_icmpv6_echo_request(…)‖ definida
no script ―HL_ZeroToHost.seq‖ é semelhante ao pacote gerado pelo script
―IH_BadIPv6Ver.seq‖ ilustrado na tabela 6, com a diferença no valor do campo Hop Limit
que é igual a zero.
As sequências de acções executadas pelo programa de execução automática no
decorrer do teste ao campo Hop Limit encontram-se listadas na tabela seguinte:
Nº Sequências de acções realizados pelo Conformance Tool
1 Start
2 Start Capturing Packets (Link0)
3 vSend(Link0,echo_request)
Send Echo Request (Hop Limit 0)
4 vRecv(Link0,ns echo_reply) timeout:5 cntLimit:0 seektime:0
Recv Echo Reply
9 OK
10 End
Tabela 21 - Acções executadas no teste ao campo Hop Limit
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 51
2.6.3. Resultado esperado do Teste
O NUT ao receber um pacote Echo Request com o campo Hop Limit a zero, deve gerar o
pacote Echo Replay correspondente, com o valor do campo Hop Limit maior do que zero
(Hop Limit default 64).
3. Testes referentes ao processamento das Opções e Cabeçalhos
de Extensões
No IPv6 existe um novo conceito de uma lista ordenada de Cabeçalhos de Extensão
(Extension Headers) que permite que os routers apenas analisem aquilo que é
necessário para o normal funcionamento da rede.
Os cabeçalhos de Extensão vem substituir o campo Options do IPv4, com vantagens,
pois enquanto este último estava limitado a 40 bytes no IPv6 o limite é apenas o tamanho
do pacote. Este campo permite assim adicionar ao cabeçalho fixo do IPv6
funcionalidades para comunicações ponto a ponto para além das básicas como o
encaminhamento de pacotes, ToS e o QoS baseado na Flow Label.
Os cabeçalhos de Extensão são os responsáveis por grande parte da eficiência do IPv6
(a utilização dos Cabeçalhos de Extensão, tem como finalidade aumentar a velocidade de
processamento dos routers, no sentido em que o único Cabeçalho de Extensão
processado em cada router é o Hop-by-Hop, os demais são tratados apenas pelo nó
identificado no Endereço Destino do cabeçalho base), podem ser vistos numa localização
intermédia, existente entre a camada de rede e a camada de transporte, não fazendo
parte do normal cabeçalho IPv6, apesar de o complementarem. Podem existir zero, um
ou mais Cabeçalhos de Extensão entre o cabeçalho IPv6 e o cabeçalho do protocolo da
camada superior. No caso de existirem vários, interligam-se todos uns com os outros
através do campo Next Header. Os Cabeçalhos de Extensão suportam funções
específicas, pré determinadas (cada um com um código identificador próprio, o Next
Header), e são adicionadas e encadeadas como necessário. Cada Extensão tem um
apontador para a próxima. À última Extensão segue-se o código para o protocolo do nível
seguinte (upper layer), já inserido no payload.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 52
Como se ilustra na figura seguinte:
IPv6 Header Next Header = TCP
TCP Header + Data
IPv6 Header Next Header = Routing
Routing Header Next Header = TCP
TCP Header + Data
IPv6 Header Next Header = Routing
Routing Header Next Header = Fragment
Fragment Header Next Header = TCP
TCP Header + Data
Figura 6 - Cabeçalho de Extensão
Com a excepção do cabeçalho Hop-by-Hop onde a informação transportada é analisada
e processada em todos os nós, os restantes apenas são processados pelo nó destino.
Quando atingido o destino, os Cabeçalhos de Extensão deverão ser sempre processadas
pela ordem indica no pacote IP.
A razão pela qual o Cabeçalho de Extensão Hop-by-Hop é uma excepção, no que
respeita ao tratamento dos Cabeçalhos de Extensão, deve-se ao facto de este campo
transportar informação que deve ser examinada e processada por todos os nós ao longo
do percurso do pacote, incluindo os nós origem e destino.
Actualmente encontram-se já definidos os seguintes Cabeçalhos de Extensão:
Valor Descrição
0 Hop-by-Hop Options Header
43 Routing Header (Tipo 0)
44 Fragment Header
50 Encapsulating Security Payload
51 Authentication Header
59 No Next Header
60 Destination Options Header
Tabela 22 - Cabeçalho de Extensão26
Alguns cabeçalhos de Extensão são bastantes parecidos e completamente novos (Hop-
by-Hop Options header, Destination Options header), outros não trazem novidades
26
A lista de Cabeçalhos de Extensão foi retirada do seguinte endereço: http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 53
(Authentication header, Encapsulating Security Payload), e outros são um aproveitamento
de alguns conceitos anteriores, misturados com algumas novidades (Routing header,
Fragment header).
O cabeçalho de extensão "Destination Options" que aparece no fim destina-se a opções
dirigidas apenas ao nó final. O outro cabeçalho "Destination Options" será processado
em todos os nós indicados no cabeçalho Routing ("Source Routing").
Os cabeçalhos de extensão que contêm opções ("Hop-by-Hop Options" e "Destination
Options") utilizam uma estrutura semelhante para armazenar as opções, as estruturas
dos cabeçalhos diferem entre si.
3.1. Pacote Echo Request usado nos testes
Pacote Echo Request usado nos vários testes encontra-se listado na tabela
seguinte:
Pacote Echo Request
Frame_Ether (length:62) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:48) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 8 | | | NextHeader = 60 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Hdr_Destination (length:8) | | | | | | (…) | | |
Tabela 23 - Pacote Echo Request usado nos testes ao Cabeçalho de extensão
Será utilizada uma primitiva específica em cada teste, que permitirá gerar um pacote
Echo Request semelhante ao pacote apresentado anteriormente (pode ter variações no
tamanho do pacote IPv6), adicionando o cabeçalho de extensão necessário para a
realização do teste em causa.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 54
3.2. Teste ao campo Next Header do cabeçalho de
Extensão
Se, como resultado do processamento de um cabeçalho, um nó necessitar de
avançar para o próximo cabeçalho mas o valor no campo Next Header não for
reconhecido pelo nó actual, este deve descartar o pacote, ou seja o não processamento
de um cabeçalho de Extensão por parte dum nó, por este não conseguir identificar o valor
no campo Next Header, implica descartar pacote e o envio de uma mensagem de
problema ICMP (ICMP Parameter Problem message) para o nó de origem do pacote.
3.2.1. Objectivo
Verificar se o nó descarta um pacote, por este não conseguir identificar o valor do
campo Next Header do cabeçalho de Extensão pelo facto do valor estar irreconhecível ou
o valor não corresponder ao Next Header esperado e se após descartar o pacote o nó
transmite uma mensagem ICMPv6 (ICMPv6 Parameter Problem message).
3.2.2. Corpo do teste
O nó de teste (TN) envia um pacote com o valor do campo Next Header do
cabeçalho Destination Options header igual a 128 (formato decimal) valor irreconhecível.
Para a realização do teste o programa de execução automática utilizou o script
“EH_UnrecognizedNextHeader.seq‖ onde se encontram definidas algumas funções
entre elas uma que permite gerar um pacote com o valor do campo Next Header do
cabeçalho de extensão irreconhecível.
Na tabela seguinte encontra-se listada a função descrita anteriormente.
Funções definidas no script EH_UnrecognizedNextHeader.seq
FEM_hdr_ipv6_exth(
unrecog,
_HETHER_tn2nut,
{
_SRC(tnv6());
_DST(nutv6());
},
{
header = _HDR_IPV6_NAME(unrecog);
exthdr = _dst;
upper = apl;
} ) Tabela 24- Função do script EH_UnrecognizedNextHeader.seq
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 55
Na tabela seguinte encontra-se listado a estrutura do pacote gerado pela função anterior.
Ao pacote Echo Request base definido anteriormente (ponto 3.1) foi adicionado o
cabeçalho de extensão.
Pacote contendo o campo Next Header do cabeçalho de extensão irreconhecível
| | Hdr_Destination (length:8) | | | NextHeader = 128 | | | HeaderExtLength = 0 | | | Opt_PadN (length:6) | | | | OptionType = 1 | | | | OptDataLength = 4 | | | | pad = 00000000 | | Payload (length:0) | | | data =
Tabela 25 - Pacote gerado pelo script EH_UnrecognizedNextHeader.seq
As sequências de acções executadas pelo programa de execução automática no
decorrer do teste ao campo versão encontram-se listadas na tabela seguinte:
Nº Sequências de acções realizados pelo Conformance Tool
1 Start
2 Start Capturing Packets (Link0)
3 vSend(Link0,unrecog)
Send Unrecognized Next Header in Extension Header
4 vRecv(Link0,ns icmperr) timeout:5 cntLimit:0 seektime:0
Recv ICMP Error Recv ICMP Error (Parameter Problem, unrecognized Next Header type encountered)
9 OK
10 End
Tabela 26 - Acções executadas no teste ao campo Next Header do cabeçalho de extensão
3.2.3. Resultado esperado do teste
O NUT ao receber um pacote com o valor do campo Next Header do cabeçalho
da extensão irreconhecível, deve gerar uma mensagem de erro ICMPv6 (Parameter
Problem message) com o valor do campo Code a 1 (Unrecognized Next Header Type
encountered) e com o campo Pointer a 0x06 (offset do campo Next Header do cabeçalho
Destino).
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 56
3.3. Teste à ordem do cabeçalho de extensão Hop-by-Hop
num pacote com mais de um cabeçalho extensão
Da mesma forma que o não processamento de um cabeçalho de Extensão por
parte dum nó, por este não conseguir identificar o valor no campo Next Header, implica
descartar pacote e o envio de uma mensagem de problema ICMP (ICMP Parameter
Problem message) para o nó de origem do pacote. Deverá ser executada a mesma
acção caso for encontrado o valor zero (0) no campo Next Header de qualquer outro
cabeçalho que não seja o cabeçalho IPv6
Quando existem mais do que um cabeçalho de Extensão num pacote, é recomendado
que estes devem aparecer pela seguinte ordem:
Cabeçalho IPv6
Cabeçalho Hop-by-Hop Options
Cabeçalho Destination Options
Cabeçalho de Routing
Cabeçalho Fragment
Cabeçalho de autenticação
Cabeçalho Encapsulating Security Payload
Cabeçalho Destination Options (para o destino
final)
Tabela 27 - Ordem dos Cabeçalhos de Extensão
Os cabeçalhos de extensão devem ser processados, estritamente, na ordem pela qual
aparecem no pacote, com excepção ao cabeçalho Hop-by-Hop, este quando presente,
tem de aparecer imediatamente a seguir ao cabeçalho IPv6, sendo a sua presença
indicada pelo valor zero (0) no campo Next Header do cabeçalho IPv6.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 57
3.3.1. Objectivo
Verificar se o nó descarta um pacote, quando existe mais do que um cabeçalho de
extensão, em que o cabeçalho Hop-by-Hop está presente, e este não aparece
imediatamente a seguir ao cabeçalho IPv6 e se após descartar o pacote o nó transmite
uma mensagem ICMPv6 (ICMPv6 Parameter Problem message).
3.3.2. Corpo do teste
O nó de teste (TN) envia um pacote Echo Request contendo um cabeçalho de
extensão Hop-by-Hop, em que este não precede o cabeçalho IPv6, isto é o valor do
campo Next Header do cabeçalho IPv6 corresponde a 60, valor este que indica que o
cabeçalho seguinte é o Destination Options Header.
Para a realização do teste o programa de execução automática utilizou o script
“EH_HBHOptAfterDstOpt.seq‖ onde se encontram definidas algumas funções entre elas
uma que permite gerar um pacote Echo Request contendo o cabeçalho de extensão Hop-
by-Hop depois do cabeçalho de extensão Destination Option Header.
Na tabela seguinte encontra-se listada a função descrita anteriormente.
Funções definidas no script EH_HBHOptAfterDstOpt.seq
FEM_icmp6_echo_request_exth(echo_request,
_HETHER_tn2nut,
{
_SRC(tnv6());
_DST(nutv6());
},
{
header =
_HDR_IPV6_NAME(echo_request);
exthdr = _dst;
exthdr = _hbh;
upper = _ICMPV6_NAME(echo_request);
},
{
payload = echo_data8;
}
)
Hdr_Destination _dst {
option = _Pad6; }
Hdr_HopByHop _hbh {
option = _Pad6; } Tabela 28 - Função do script EH_HBHOptAfterDstOpt.seq
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 58
Na tabela seguinte encontra-se listado a estrutura do pacote gerado pela função anterior.
Pacote Echo Request contendo o cabeçalho de extensão Hop-by-Hop depois do
cabeçalho de extensão Destination Option Header
| Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:72) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 32 | | | NextHeader = 60 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Hdr_Destination (length:8) | | | NextHeader = 0 | | | HeaderExtLength = 0 | | | Opt_PadN (length:6) | | | | OptionType = 1 | | | | OptDataLength = 4 | | | | pad = 00000000 | | Hdr_HopByHop (length:8) | | | NextHeader = 58 | | | HeaderExtLength = 0 | | | Opt_PadN (length:6) | | | | OptionType = 1 | | | | OptDataLength = 4 | | | | pad = 00000000 | | ICMPv6_EchoRequest (length:16) | | | Type = 128 | | | Code = 0 | | | Checksum = 37889 calc(37889) | | | Identifier = 0 | | | SequenceNumber = 0 | | | Payload (length:8) | | | | data = 01020304 05060708
Tabela 29 - Pacote gerado pelo script EH_HBHOptAfterDstOpt.seq
As sequências de acções executadas pelo programa de execução automática no
decorrer do teste à ordem do cabeçalho de extensão Hop-by-Hop encontram-se listadas
na tabela seguinte:
Nº Sequências de acções realizados pelo Conformance Tool
1 Start
2 Start Capturing Packets (Link0)
3 vSend(Link0,echo_request)
Send Echo Request (Hop-by-Hop Options Header after Destination Options Header)
4 vSend(Link0,echo_request)
Send Echo Request (Hop-by-Hop Options Header after Destination Options Header)
9 OK
10 End
Tabela 30 - Acções executadas no teste à ordem do cabeçalho de extensão Hop-by-Hop
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 59
3.3.3. Resultado esperado do teste
O NUT ao receber um pacote Echo Request contendo um cabeçalho de extensão
Hop-by-Hop, em que este não precede o cabeçalho IPv6, deverá enviar uma mensagem
de erro ICMPv6 (Parameter Problem message) com o valor do campo Code a 1
(Unrecognized Next Header Type encountered).
3.4. Teste ao cabeçalho de extensão Hop-by-Hop
O Cabeçalho de opções Hop-by-Hop é usado para transportar informação opcional
que deve ser analisada em todos os nós ao longo do percurso de um pacote. É
identificado pelo valor zero (0) no campo Next Header do cabeçalho IPv6. É o cabeçalho
utilizado, quando não existe qualquer estratégia possível de poupança de processamento
a alguns routers, para se obter a função pretendida.
A figura seguinte ilustra o Cabeçalho de Extensão Hop-by-Hop e a respectiva captura.
Options
Next HeaderHeader Extension
Lenght
Figura 7 - Cabeçalho Hop-by-Hop Option
Figura 8 - Captura do Cabeçalho Hop-by-Hop Option
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 60
Análise da figura Captura do Cabeçalho Hop-by-Hop Option
A estrutura do cabeçalho é bastante simples. Existe o campo Next Header, depois
um campo responsável pelo tamanho da opção e a respectiva opção. No final, poderá ser
necessário um campo de padding, para completar o tamanho do pacote.
O campo Next Header do cabeçalho IPv6 contém o valor zero (0), correspondente ao
Hop-by-Hop Options, pela numeração definida. De seguida, o campo Next Header do
cabeçalho Hop-by-Hop Options contém o valor para o próximo cabeçalho ICMPv6.
A opção escolhida neste caso foi a Router Alert. [12] Esta opção exclusiva do IPv6
permite dar informações adicionais aos routers de como tratar o pacote. Este tipo de
informação adicional refere-se à informação que não pode ser transportada, no normal
cabeçalho IP.
O Cabeçalho de Extensão Hop-by-Hop é constituído pelos campos Next Header,
Header Extension Length e Options que contém uma ou mais opções. O valor do campo
Header Extension Length é composto pelo número de blocos de 8 bytes contido no
campo Options Extension Header, não incluindo os primeiros 8 bytes. No entanto, para
um Hop-by-Hop Options Header de 8 bytes, o valor do campo Options Extension Header
é 0.
As restantes opções são usadas para garantir limites de 8 bytes. O campo Header
Extension Length é um dos exemplos de como foram feitos os possíveis para optimizar o
processamento de pacotes IPv6 nos routers intermediários.
Uma das primeiras operações a ser feita aos pacotes IPv6 é determinar o tamanho do
seu cabeçalho. Para garantir robustez na implementação de IPv6, os campos cujos
valores validos comecem pelo valor 1 têm de ser verificados para que não permitam que
o valor 0 lhes seja atribuído. Esta verificação tem de ser feita antes de qualquer
processamento adicional seja feito.
Correntemente, o valor 0 é um valor válido e não é preciso efectuar qualquer verificação
de valores inválidos pois o número de bytes no Hop-by-Hop Options Header é calculado
de acordo com a seguinte fórmula: (tamanho do Header Extension + 1) x 8, ou seja, é
sempre adicionado o valor 1 para que nunca ocorra o caso deste campo assumir o valor
0.
Uma opção é um grupo de campos que descreve características específicas de entrega
de pacotes. As opções são enviadas no cabeçalho Hop-by-Hop Options e no cabeçalho
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 61
Destination Options. Cada opção está codificada no formato TLV (Type-Length-Value)
que é normalmente utilizado nos protocolos TCP/IP
Option Type Opt Data Len Option Data
Figura 9 - Formato do campo opções.
Podemos observar os seguintes campos:
Option Type – identifica a opção e determina a forma como ela vai ser tratada
pelo nó.
Opt Data Len – O campo Option Data Length indica o número de bytes da opção,
não incluindo os primeiros 8 octetos.
Option Data – campo de dimensão variável que identifica os dados específicos
associados à opção.
Uma opção pode ter necessidade de preparação para garantir que os campos
específicos que se encontram dentro da opção se encontrem nos desejados limites
(múltiplo de 8 bytes). Por exemplo, é mais fácil processar um endereço IPv6 se este
estiver limitado a 8 bytes.
A necessidade de preparação é expressa utilizando a notação xn + y, indicando que essa
opção tem de começar nos limites de um byte igual ao inteiro múltiplo de x bytes mais y
bytes desde o início do cabeçalho Para facilitar a preparação requerida, o
encapsulamento ocorre antes de uma opção e é feita entre cada opção quando existem
múltiplas opções definidas.
A sequência de opções dentro do cabeçalho deve ser processado pela mesma ordem
que aparecem no cabeçalho, o receptor não deve, por exemplo, pesquisar por um tipo de
opção particular dentro do cabeçalho, antes de processar todas as anteriores.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 62
3.5. Teste ao campo Opção Pad1/PadN do cabeçalho de
extensão Hop-by-Hop
Existem duas opções de enchimento (padding Options): Pad1 e PadN que são
usados quando necessários para alinhar as opções subsequentes e para preencherem o
tamanho do cabeçalho com múltiplos de 8 octetos.
As opções devem ficar alinhadas a 32 bits com o cabeçalho. Nos casos em que basta um
octeto para garantir o alinhamento usa-se a opção Pad 1 (tipo=0), correspondendo a um
enchimento com os 8 bits zero. A opção Pad1 é o único caso particular que não respeita
a estrutura geral das opções.
Quando seja necessário mais do que um octeto utiliza-se a opção PadN (tipo=1), com o
comprimento necessário para o enchimento (o campo "Data Length" pode conter o valor
zero, correspondendo a dois octetos de enchimento).
As opções de enchimento (padding Options) devem ser reconhecidas por todas as
implementações IPv6:
Pad1 Option (alignment requirement: none)
0
Figura 10 – Valor do tipo de opção Pad1 de um pacote IPv6
O formato da opção Pad1 é um caso especial – que não tem o comprimento nem o valor
do campo.
É utilizado para inserir um octeto de enchimento para a área ―Options‖ do cabeçalho. No
caso de ser preciso mais do que um octeto de enchimento, deve ser utilizado a opção
PadN Option, ao invés de múltiplas opções Pad1.
PadN Option (alignment requirement: none)
1 Opt Data Len Option Data
Figura 11 - PadN Option.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 63
A opção PadN é usada para inserir dois ou mais octetos de enchimento na área Options
do cabeçalho. Para N octetos de enchimento, o campo de dados Opt Len contém o N-2,
e Option Data consiste em N-2 valor zero octetos.
3.5.1. Objectivo
Verificar se um nó processa correctamente as opções e age de acordo com os 2
bits de maior ordem da opção
3.5.2. Corpo do teste
Para realizar o teste Pad1 o nó de teste (TN) envia um pacote Echo Request
contendo um cabeçalho de Extensão Hop-by-Hop Options com seis opções Pad1.
Para realizar o teste PadN o nó de teste (TN) envia um pacote Echo Request
contendo um cabeçalho de Extensão Hop-by-Hop Options com 6 bytes PadN Option.
Para a realização do teste Pad1 e PadN o programa de execução automática utilizou o
script “HH_Pad1.seq‖ e ―HH_PadN.seq‖, onde se encontram definidas algumas
primitivas que permitem gerar um pacote Echo Request contendo um cabeçalho de
Extensão Hop-by-Hop Options com seis opções Pad1 e com 6 bytes PadN Option
respectivamente.
Na tabela seguinte encontra-se listada a função descrita anteriormente.
Primitivas usadas para gerar o cabeçalho Hop-by-Hop Pad1/PadN
Primitivas #define OPT_PAD opt_Pad1
#define OPT_PAD opt_PadN
Echo Request Pad1 %pktdesc = (
echo_request_ex => 'Send Echo Request (Hop-
by-Hop Options:Pad1)' );
Echo Request PadN %pktdesc = (
echo_request_ex => 'Send Echo Request (Hop-
Echo Request Pad1by-Hop Options:PadN)' );
Tabela 31 - Função do script EH_HBHOptAfterDstOpt.seq
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 64
Na tabela seguinte encontram-se listados as estruturas dos pacotes gerados pelas
funções anteriores.
Pacote Echo Request contendo o cabeçalho de extensão Hop-by-Hop Pad1
Frame_Ether (length:78) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:64) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 24 | | | NextHeader = 0 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Hdr_HopByHop (length:8) | | | NextHeader = 58 | | | HeaderExtLength = 0 | | | Opt_Pad1 (length:1) | | | | OptionType = 0 | | | Opt_Pad1 (length:1) | | | | OptionType = 0 | | | Opt_Pad1 (length:1) | | | | OptionType = 0 | | | Opt_Pad1 (length:1) | | | | OptionType = 0 | | | Opt_Pad1 (length:1) | | | | OptionType = 0 | | | Opt_Pad1 (length:1) | | | | OptionType = 0 | | ICMPv6_EchoRequest (length:16) | | | Type = 128 | | | Code = 0 | | | Checksum = 37889 calc(37889) | | | Identifier = 0 | | | SequenceNumber = 0 | | | Payload (length:8) | | | | data = 01020304 05060708
Pacote Echo Request contendo o cabeçalho de extensão Hop-by-Hop PadN
Frame_Ether (length:78) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:64) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 24 | | | NextHeader = 0 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Hdr_HopByHop (length:8) | | | NextHeader = 58 | | | HeaderExtLength = 0 | | | Opt_PadN (length:6) | | | | OptionType = 1 | | | | OptDataLength = 4 | | | | pad = 00000000 | | ICMPv6_EchoRequest (length:16) | | | Type = 128 | | | Code = 0 | | | Checksum = 37889 calc(37889) | | | Identifier = 0 | | | SequenceNumber = 0 | | | Payload (length:8) | | | | data = 01020304 05060708
Tabela 32 - Pacote gerado pelo script HH_Pad1.seq e HH_PadN.seq
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 65
Como se pode ver no pacote Hop-by-Hop PadN apresentado na tabela anterior, para N
octetos de enchimento (N = 6), o campo de dados Opt Len contém o N-2, ou seja o valor
do campo Opt Len é igual a 4.
As sequências de acções executadas pelo programa de execução automática no
decorrer do teste ao campo Opção Pad1/PadN do cabeçalho de extensão Hop-by-Hop
encontram-se listadas na tabela seguinte:
Sequências de acções realizados pelo Conformance Tool
Nº Pad1 PadN
1 Start
2 Start Capturing Packets (Link0)
3 vSend(Link0,echo_request_ex)
Send Echo Request (Hop-by-Hop
Options:Pad1)
vSend(Link0,echo_request_ex)
Send Echo Request (Hop-by-Hop Options:PadN)
4 vRecv(Link0,ns echo_reply echo_reply_ex)
timeout:5 cntLimit:0 seektime:0
Recv Echo Reply
vRecv(Link0,ns echo_reply echo_reply_ex)
timeout:5 cntLimit:0 seektime:0
Recv Echo Reply
5 OK
End
Tabela 33 - Acções executadas no teste ao campo Opção Pad1/PadN
3.5.3. Resultado esperado do teste
O NUT ao receber um pacote Echo Request contendo um cabeçalho Hop-by-Hop
com seis Pad1 Option ou com 6 bytes PadN Option, deverá responder com um Echo
Replay para o TN.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 66
3.6. Teste à codificação dos dois bits de maior ordem do
indicador Option Type
Os identificadores Option Type são internamente codificados no formato TLV
(Type-Length-Value) de tal forma que os dois bits de maior ordem (bits mais
significativos) especificam a acção que deve ser tomado caso o nó que processa o
pacote não reconheça o tipo da opção:
Valor Acção
00 Ignorar a opção e continuar o processamento do cabeçalho
01 Descartar o pacote
10 Descartar o pacote e, independentemente do endereço de destino ser um endereço
Multicast ou não enviar uma mensagem ICMP (ICMP - Parameter Problem), com o
campo Code 2, a mensagem deve ser enviada ao endereço Origem do pacote
11 Descartar o pacote e, e enviar uma mensagem ICMP (ICMP - Parameter Problem)
apenas se o endereço de destino não for um endereço Multicast
Tabela 34 - Identificadores Option Type
O terceiro bit de maior ordem (3º bit mais significativo) do indicador Option Type
especifica se durante o percurso o campo Option Data pode ou não sofrer alterações
(mudar de rota para o destino final). O valor zero (0) indica que não se pode mudar de
rota e um (1) indica que pode mudar de rota. Esta "flag" é importante na presença de um
cabeçalho de extensão de autenticação. Quando este bit possui valor, para efeitos de
validação os dados respeitantes a esta opção serão considerados zero.
Valor Acção
0 Opção de dados não mudar de rota
1 Opção de dados pode mudar de rota
Tabela 35 – Terceiro bit mais significativo do Option Type
Os três bits de maior ordem (os 3 bits mais significativos) acima descritos devem ser
tratados como parte da Option Type, e não de forma independente da Option Type. Ou
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 67
seja, uma determinada opção é identificada pelo seu identificador Option Type que são 8-
bit, não apenas pelos 5 bits de menor ordem da Option Type.
A mesma numeração do Option Type é usada tanto para o cabeçalho Hop-by-Hop como
para o cabeçalho Destination Options. No entanto, a especificação de uma determinada
opção pode restringir sua utilização para apenas um desses dois cabeçalhos.
Opções individuais (individual Option) podem ter requisitos de alinhamento específicos,
para garantir valores múltiplos de 8 octetos no campo Option Data. Por exemplo, é mais
fácil processar um endereço IPv6 se este estiver limitado a 8 bytes.
3.6.1. Objectivo
Verificar se um nó processa correctamente as opções e age de acordo com os 2 bits
de maior ordem do identificador Option Type.
3.6.2. Corpo do Teste
O nó de teste (TN) envia um pacote Echo Request para o nó em teste (NUT),
contendo um cabeçalho de Extensão Hop-by-Hop Options com o valor do campo Option
Type desconhecido, em que os dois bits de maior ordem do identificador Option Type
assumem os seguintes valores:
a) Option Type (00)
b) Option Type (01)
c) Option Type (10)
d) Option Type (11), sendo o endereço destino um Multicast local
Para a realização do teste para as situações a,b,c e d o programa de execução
automática utilizou os scripts HH_Type00.seq, HH_Type01.seq, HH_Type10.seq e
HH_Type11.seq respectivamente.
Na tabela seguinte encontra-se listada algumas primitivas usadas no script para gerar os
pacotes de teste.
Primitivas usadas para gerar o cabeçalho Hop-by-Hop Pad1/PadN
Primitivas #define OPT_PAD opt_Type00
#define OPT_PAD opt_Type01
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 68
#define OPT_PAD opt_Type10
#define OPT_PAD opt_Type11
opt_Type01 %pktdesc = (
echo_request => 'Send Echo Request
(Preparation)',
echo_request_ex => 'Send Echo Request
(Unrecognized Option:Type 01)');
Tabela 36 – Primitivas usadas no script HH_Type.seq
Na tabela seguinte encontram-se listados as estruturas dos pacotes contendo o
cabeçalho de Extensão Hop-by-Hop Options com o valor do campo Option Type
desconhecido gerados pelas primitivas listadas anteriormente.
Option Type (00)
| | Hdr_HopByHop (length:8) | | | NextHeader = 58 | | | HeaderExtLength = 0 | | | Opt_ANY (length:6) | | | | OptionType = 2 | | | | OptDataLength = 4 | | | | data = 00000000
(…)
Option Type (01)
| | Hdr_HopByHop (length:8) | | | NextHeader = 58 | | | HeaderExtLength = 0 | | | Opt_ANY (length:6) | | | | OptionType = 66 | | | | OptDataLength = 4 | | | | data = 00000000
Option Type (10)
| | Hdr_HopByHop (length:8) | | | NextHeader = 58 | | | HeaderExtLength = 0 | | | Opt_ANY (length:6) | | | | OptionType = 130 | | | | OptDataLength = 4 | | | | data = 00000000
Option Type (11)
| | Hdr_HopByHop (length:8) | | | NextHeader = 58 | | | HeaderExtLength = 0 | | | Opt_ANY (length:6) | | | | OptionType = 226 | | | | OptDataLength = 4 | | | | data = 00000000
Tabela 37 - Pacotes gerados pelo script HH_Type.seq
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 69
3.6.3. Resultado esperado do teste
O NUT ao receber um pacote Echo Request contendo um cabeçalho Hop-by-Hop
com o valor do campo Option Type desconhecido deverá agir de acordo com os dois bits
de maior ordem do identificador Option Type.
a) Option Type (00) – deverá ignorar a opção e continuar o processamento
do cabeçalho
b) Option Type (01) – deverá descartar o pacote
c) Option Type (10) – deverá descartar o pacote e, independentemente do
endereço de destino ser um endereço Multicast ou não enviar uma
mensagem ICMP (ICMP - Parameter Problem), com o campo Code igual a
2, a mensagem deve ser enviada ao endereço Origem do pacote
d) Option Type (11) – deverá descartar o pacote e, e enviar uma mensagem
ICMP (ICMP - Parameter Problem) apenas se o endereço de destino não
for um endereço Multicast
4. Testes referentes à fragmentação no IPv6
O conceito de fragmentação não é novo, assim como a versão 4 do protocolo IP a
versão 6 também suporta a fragmentação de pacotes. A grande diferença está na forma
como a fragmentação é efectuada. Em IPv6 a fragmentação é feita pelo nó de origem
antes do envio do pacote. É utilizada a técnica de enviar um Path MTU27 Discovery para
descobrir qual o menor dos MTU´s até ao destino. No processo de envio do pacote, o nó
de origem fragmenta-o de maneira que cada fragmento seja inferior ou igual ao MTU
mínimo descoberto. Desta forma, a fragmentação não ocorre nos routers intermédios.
27
Path MTU - mais pequeno MTU num caminho entre duas máquinas
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 70
A figura seguinte ilustra o cabeçalho de extensão Fragment.
Next Header Reserved Fragment Offset Res M
Identification
Figura 12 - Cabeçalho de Extensão Fragmentation
As definições de cada campo do cabeçalho são as seguintes:
Next Header (8 bits) – o campo Next Header identifica o tipo do próximo
cabeçalho de extensão;
Reserved – o campo Reserved é reservado para utilização futura;
Fragment Offset – o campo Fragment Offset indica a que ponto do pacote
original pertence o fragmento;
Res – o campo Res é reservado para utilização futura;
M – a flag M indica se existem mais fragmentos ou se, se trata do último
fragmento. Este campo admite um de dois valores:
Valor Descrição
0 Indica que é o último fragmento
1 Indica que existem mais
fragmentos
Tabela 38 – Bit M do cabeçalho de extensão Fragment
Identification – o campo Identification identifica de forma unívoca o fragmento. O
número de bits deste campo foi ampliado relativamente ao IPv4, devido às redes
de alta velocidade.
O cabeçalho de extensão Fragment é identificado pelo valor 44 no campo Next Header
do cabeçalho IPv6, e é utilizado quando o pacote IPv6 a ser enviado é maior que o
caminho para o destino. Nessas situações o nó de origem divide o pacote em vários
fragmentos e envia cada fragmento como um pacote separado. No destino são
reagrupados os vários fragmentos.
Para todos os pacotes fragmentados é gerado, pelo nó de origem, um valor de
Identificação. Este valor de identificação é diferente de qualquer outro pacote
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 71
fragmentado que não tenha sido enviado recentemente com o mesmo endereço de
origem e destino. O termo recentemente corresponde ao período máximo de vida
provável de um pacote, incluindo o tempo de trânsito da origem para o destino e o tempo
gasto na reconstrução. Porém, não se requer a um nó de origem que conheça o período
máximo de vida de um pacote. Assume-se que um valor de identificação de 32 bits para
um contador cíclico de identificação é suficiente. [10]
Num pacote existe informação que não é possível fragmentar, separando-se
assim duas partes distintas, a parte fragmentável e a parte não fragmentável.
Para a análise seguinte o termo ―pacote inicial‖ considera-se como sendo o pacote
grande e não fragmentado.
Parte não Fragmentável
Parte Fragmentável
Figura 13 - Fragmentação de pacotes.
A parte não fragmentável consiste no cabeçalho IPv6 mais os cabeçalhos de extensão
que devem ser processados pelos nós até ao destino, por exemplo, cabeçalho de routing
e cabeçalho Hop-by-Hop.
A parte fragmentável engloba o resto do pacote, isto é, todos os cabeçalhos de extensão,
que apenas têm que ser processados pelo nó de destino, mais o cabeçalho da camada
superior e os dados.
A parte fragmentável do pacote original é dividida em fragmentos. Com excepção do
último, o comprimento de cada fragmento é múltiplo de 8 octetos. Os fragmentos são
transmitidos em ―pacotes fragmentados‖ separados como se ilustra na figura seguinte:
Parte não Fragmentável
1º Fragmento 2º Fragmento ... Ultimo Fragmento
Figura 14 - Pacote original.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 72
Parte não Fragmentável
Cabeçalho de Fragmentação
1º Fragmento
Parte não Fragmentável
Cabeçalho de Fragmentação
2º Fragmento
Parte não Fragmentável
Cabeçalho de Fragmentação
Ultimo Fragmento
Figura 15 - Pacotes fragmentados.
A composição de cada pacote fragmentado é a seguinte:
Parte não fragmentável do pacote inicial, com uma alteração no tamanho do
payload relativamente ao inicial. O tamanho do payload é alterado
correspondendo agora a apenas ao tamanho do fragmento, excluindo inclusive o
tamanho do cabeçalho IPv6. O campo Next Header do último campo da parte não
fragmentável é alterado para 44 de forma a indicar a presença dos fragmentos.
O cabeçalho do fragmento é composto por:
O valor do campo Next Header que identifica o primeiro cabeçalho da parte
fragmentável do pacote original;
O campo Fragment Offset indica a distância do fragmento, em unidades de 8
octetos, relativamente ao começo da parte fragmentável do pacote original. O
Fragment Offset do primeiro fragmento é 0;
A flag M que, caso seja 0, indica o último fragmento;
Uma identificação;
O próximo fragmento.
A parte não fragmentável do pacote reconstituído é composta por todos os
cabeçalhos até ao cabeçalho de fragmento, com exclusão deste, do primeiro pacote
fragmentado, (ou seja, o pacote cujo Fragment Offset é zero) com duas alterações.
O campo Next Header do último cabeçalho da parte não fragmentável é obtido do
campo Next Header do primeiro cabeçalho de fragmento, da parte fragmentável.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 73
O tamanho do Payload do pacote reconstituído é calculado a partir do tamanho
da parte não fragmentável e do tamanho do Offset do último fragmento.
A parte fragmentável do pacote reconstituído é construída com fragmentos que
seguem ao cabeçalho de fragmento em cada um dos pacotes de fragmento. O tamanho
de cada fragmento é calculado subtraindo ao tamanho do Payload do pacote o tamanho
dos cabeçalhos entre o cabeçalho IPv6 e o do próprio fragmento, a sua posição relativa
na parte fragmentável é calculada a partir do seu valor de Fragment Offset. O cabeçalho
de fragmentação não esta presente no pacote final reconstituído.
Na reconstituição do pacote podem surgir as seguintes situações de erro:
Se são recebidos fragmentos insuficientes para completar a reconstituição de um
pacote num intervalo de 60 segundos, desde a recepção do primeiro fragmento
que foram recebidos devem ser descartados.
Se o tamanho de um fragmento, como derivou do tamanho do campo Payload
Length do pacote de fragmento, não é um múltiplo de 8 octetos e a flag M daquele
fragmento é 1, então aquele fragmento deve ser descartado e uma mensagem de
ICMPv6 (ICMPv6 Parameter Problem), código zero (0), deve ser enviada à fonte
do fragmento, apontando o problema no campo Payload Length do pacote de
fragmento.
Se o tamanho e o Offset de um fragmento são tais que o tamanho do Payload do
pacote reconstituído excederia 65.535 bytes, então o fragmento deve ser
descartado e uma mensagem de ICMP (ICMP Parameter Problem), código zero
(0), deve ser enviada à fonte do fragmento, apontando para o campo Fragment
Offset do pacote.
Existem outras situações que, em regra, podem não ocorrer, mas caso ocorram não são
consideradas erro. Essas situações são:
O número e conteúdo dos cabeçalhos que procedem o cabeçalho de fragmento,
de fragmentos diferentes do mesmo pacote original, podem diferir. Sempre que
existam cabeçalhos antes do cabeçalho de fragmento são processados quando o
pacote chega, antes dos fragmentos serem guardados para reconstituição.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 74
Os valores do campo Next Header nos cabeçalhos de fragmento, de fragmentos
diferentes do mesmo pacote original, podem diferir. Só o valor do campo do
fragmento com Offset zero é usado para a reconstituição.
4.1. Fragmentos de pacote usados nos testes
Na tabela seguinte encontram-se listados as estruturas dos dois fragmentos de
um pacote Echo Request usados nos vários testes.
Fragmento 1
Frame_Ether (length:582) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:568) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 528 | | | NextHeader = 44 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Hdr_Fragment (length:8) | | | NextHeader = 58 | | | Reserved1 = 0 | | | FragmentOffset = 0 | | | Reserved2 = 0 | | | MFlag = 1 | | | Identification = 235 | | Payload (length:520)
Fragmento 2
Frame_Ether (length:574) | Hdr_Ether (length:14) | | DestinationAddress = 00:0c:29:1f:b2:72 | | SourceAddress = 00:00:00:00:01:00 | | Type = 34525 | Packet_IPv6 (length:560) | | Hdr_IPv6 (length:40) | | | Version = 6 | | | TrafficClass = 0 | | | FlowLabel = 0 | | | PayloadLength = 520 | | | NextHeader = 44 | | | HopLimit = 64 | | | SourceAddress = fe80::200:ff:fe00:100 | | | DestinationAddress = fe80::20c:29ff:fe1f:b272 | | Hdr_Fragment (length:8) | | | NextHeader = 58 | | | Reserved1 = 0 | | | FragmentOffset = 65 | | | Reserved2 = 0 | | | MFlag = 0 | | | Identification = 235 | | Payload (length:512)
Tabela 39 – Fragmentos de um Pacote Echo Request usado nos testes à fragmentação
Como se pode ver na tabela anterior o campo Next Header do cabeçalho IPv6 é igual a
44 de forma a indicar a presença dos fragmentos. O campo FragmentOffset do
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 75
fragmento1 é igual a zero (0), visto que o valor deste campo do primeiro fragmento é 0, e
o tamanho do campo payload corresponde apenas ao tamanho do fragmento, excluindo
inclusive o tamanho do cabeçalho IPv6.
4.2. Teste à reconstituição de fragmentos (ordem normal/
ordem inversa)
O tamanho dos fragmentos é escolhido de acordo com o MTU do caminho para o
destino dos pacotes. No destino os fragmentos são reconstituídos, de forma a reconstruir
o pacote original. Um pacote original é reconstituído apenas com os pacotes de
fragmento que tenham o mesmo Endereço de Origem, Endereço de Destino e
Identificação de fragmento.
4.2.1. Objectivo
Verificar se o NUT reconstitui correctamente os fragmentos e se faz a distinção
entre fragmentos usando o Endereço de Origem, Endereço de Destino e Identificação de
fragmento e também verificar se após receber os fragmentos pela ordem inversa os
reconstitui correctamente.
4.2.2. Corpo do teste
O nó de teste (TN) envia um pacote dividido em dois fragmentos (Fragmento 1 e
fragmento 2) contendo o mesmo Endereço de Origem, Endereço de Destino e
Identificação de fragmento.
Para o teste à ordem inversa dos pacotes o TN envia os dois fragmentos em que
o primeiro fragmento a ser enviado é o fragmento 2 que corresponde ao último fragmento
e de seguida o fragmento 1 que corresponde ao primeiro fragmento.
Para a realização dos testes o programa de execução automática utilizou os scripts
“FH_Normal.seq e FH_Reverse.seq‖ onde se encontram definidas primitivas que
permitem gerar vários fragmentos de um pacote.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 76
Na tabela seguinte encontra-se listada a função descrita anteriormente.
Primitivas usadas para gerar fragmentos de um pacote
Primitivas usadas na construção do fragmento 1
Hdr_Fragment frag_1st {
NextHeader = 58;
FragmentOffset = 0;
MFlag = 1;
Identification = FRAG_ID;
}
Payload payload_1st {
data =
substr(_PACKET_IPV6_NAME(echo_request), 40, 520);
} Primitivas usadas na construção do fragmento 2
Hdr_Fragment frag_2nd {
NextHeader = 58; // ignored
FragmentOffset = 65; // 520/8
MFlag = 0;
Identification = FRAG_ID;
}
Payload payload_2nd {
data =
substr(_PACKET_IPV6_NAME(echo_request), 560, 512);
}
Pacote Echo Request do 1º fragmento
FEM_hdr_ipv6_exth(
echo_request_1st,
_HETHER_tn2nut,
{
_SRC(tnv6());
_DST(nutv6());
},
{
header =
_HDR_IPV6_NAME(echo_request_1st);
exthdr = frag_1st;
upper = payload_1st;
}
)
Pacote Echo Request do 2º fragmento
FEM_hdr_ipv6_exth(
echo_request_2nd,
_HETHER_tn2nut,
{
_SRC(tnv6());
_DST(nutv6());
},
{
header =
_HDR_IPV6_NAME(echo_request_2nd);
exthdr = frag_2nd;
upper = payload_2nd;
}
)
Tabela 40 – Primitivas usadas para gerar fragmentos de um pacote
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 77
4.2.3. Resultado esperado do teste
O NUT ao receber os dois fragmentos (fragmento 1 e fragmento 2) enviados pelo
nó de teste (TN), pela ordem normal ou inversa, deverá reconstitui-los e enviar um pacote
Echo Replay para o TN, em resposta ao pacote Echo Request resultante da
reconstituição dos dois fragmentos.
4.3. Teste à reconstituição de fragmentos (Payload size =
65.536 bytes)
Se o tamanho e o Offset de um fragmento são tais que o tamanho do Payload do
pacote reconstituído exceda 65.535 bytes, então o fragmento deve ser descartado e uma
mensagem de ICMP (ICMP Parameter Problem), deve ser enviada ao nó de origem do
fragmento.
4.3.1. Objectivo
Verificar se o fragmento é descartado quando o tamanho do campo Payload do
pacote reconstituído excede os 65.535 bytes, e se é enviado uma mensagem de ICMP
(ICMPV6 Parameter Problem), código zero (0) para o nó de teste (TN). O MTU utilizado é
1500 (Ethernet)
4.3.2. Corpo do teste
O nó de teste (TN) envia 46 fragmentos para o NUT, sendo 45 fragmentos
contendo o campo Payload igual 1448 bytes e 1 fragmento contendo o campo Payload
igual a 376 bytes o que faz com que o tamanho do campo Payload do pacote
reconstituído seja igual a 65.536.
Para a realização dos testes o programa de execução automática utilizou os scripts
“FH_Big65536.seq‖ onde se encontram definidas primitivas que permitem gerar vários
fragmentos de um pacote.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 78
As sequências de acções executadas pelo programa de execução automática no
decorrer deste teste encontram-se listadas na tabela seguinte:
Nº Sequências de acções realizados pelo Conformance Tool
1 Start
2 Start Capturing Packets (Link0)
3 vSend(Link0,echo_request_1)
Send Echo Request fragment 1
… …
48 vSend(Link0,echo_request_45)
Send Echo Request fragment 45
49 vSend(Link0,echo_request_46)
Send Echo Request fragment 46
50 vRecv(Link0,icmp_type4_code0) timeout:5 cntLimit:0 seektime:0
Recv ICMP Error (Parameter Problem, erroneous header field encountered)
51 OK
52 End
Tabela 41 - Acções executadas no teste ao campo Opção Pad1/PadN
4.3.3. Resultado esperado do teste
Se o tamanho do campo Payload do pacote reconstituído pelo NUT exceda os
65.535 bytes, então o NUT deverá descartar o fragmento e enviar uma mensagem de
ICMP (ICMP Parameter Problem), para o TN.
4.4. Teste à reconstituição de fragmentos quando é
excedido o tempo (1st only)
Se são recebidos fragmentos insuficientes para completar a reconstituição de um
pacote num intervalo de 60 segundos, desde a recepção do primeiro, os fragmentos
recebidos devem ser descartados.
Capítulo IV – Descrição dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 79
4.4.1. Objectivo
Verificar o que acontece quando são recebidos fragmentos insuficientes para
completar a reconstituição de um pacote num intervalo superior a 60 segundos.
4.4.2. Corpo do teste
O nó de teste (TN) envia um pacote Echo Request contendo o único fragmento
(fragmento 1) enviado para o NUT. Fragmento este contendo a flag M a 1, o que indica
que existem mais fragmentos.
Para a realização do teste o programa de execução automática utilizou o script
./FH_1stOnly.seq.
As sequências de acções executadas pelo programa de execução automática no
decorrer do teste encontram-se listadas na tabela seguinte.
Nº Sequências de acções realizados pelo Conformance Tool
1 Start
2 Start Capturing Packets (Link0)
3 vSend(Link0,echo_request_1st)
Send Echo Request (1st fragment only)
4 vRecv(Link0,time_exceeded_1st) timeout:65 cntLimit:0 seektime:0
5 OK
6 End
Tabela 42- Acções executadas no teste à reconstituição de fragmentos
4.4.3. Resultado esperado do teste
O NUT não deve gerar um Echo Replay para o TN, uma vez que não recebeu
todos os fragmentos. Deverá descartar o pacote e enviar uma mensagem de erro
ICMPv6 (ICMPv6 – Fragment Reassembly Time Exceeded).
Exploração da Implementação actual de IPv6 no Kernel do Linux 80
Capítulo V
Resultado dos Testes Realizados
1.1. Considerações Gerais
Neste capítulo será feito a análise aos resultados dos vários testes de
conformidade IPv6 realizados no capítulo anterior, testes esses que capítulo abrangem a
especificação base do IPv6, definidos no RFC 2460, bem como o processamento das
Opções e Cabeçalhos de Extensões, em particular o Hop-by-Hop Option, Destination
Option. E também será efectuado uma comparação dos resultados obtidos do mesmo
conjunto de testes efectuados sobre outras distribuições linux.
1.2. Resultado dos testes
Os resultados dos vários testes de conformidade em relação ao IPv6 realizados
encontram-se listados na tabela na tabela seguinte.
Nº Nome do teste Resultado
1 Campo Versão errado Passou
2 Traffic Class Passou
3 Flow Label Passou
4 Payload Length Passou
Capítulo V – Resultado dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 81
5 Next Header do cabeçalho IPv6 irreconhecível
Passou
6 Hop Limit Passou
7 Next Header do cabeçalho de extensão irreconhecível
Passou
8 Teste à ordem do cabeçalho de extensão Hop-by-Hop num pacote com mais de um cabeçalho
Passou
9/ 10 Teste ao campo Opção Pad1/PadN do cabeçalho de extensão Hop-by-Hop
Passou
11
a
Teste à codificação dos dois bits de maior ordem do indicador Option Type 00
Passou
11 b Teste à codificação dos dois bits de maior ordem do indicador Option Type 01
Passou
11 c Teste à codificação dos dois bits de maior ordem do indicador Option Type 10
Passou
11 d Teste à codificação dos dois bits de maior ordem do indicador Option Type 11
Passou
12 a Teste à fragmentação ordem normal Passou
12 b Teste à fragmentação ordem inversa Passou
13 Teste à reconstituição de fragmentos superiores a 65.536
Passou
14 Teste à reconstituição de fragmentos quando é excedido o tempo
Passou
Tabela 43 - Resultado dos Testes de Conformidade IPv6 realizados
Capítulo V – Resultado dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 82
1.3. Análise dos resultados
Baseando-se no valor de retorno da execução dos scripts de teste e da análise das
sequencias de acções executadas pelo programa de execução automática no decorrer de
cada teste conclui-se que:
Nº 1 - O NUT passou no teste. Ao receber o primeiro pacote Echo Request inválido, o
NUT não gera nenhum pacote Echo Reply (como se pode ver na acção nº4 o vRec()
terminou com timeout), ao receber um segundo pacote que já é um pacote Echo Request
valido o NUT gera e envia um pacote Echo Replay.
Nº 2 – O NUT passou no teste. Ao receber um pacote Echo Request com o valor do
campo Traffic Class igual a 0x12 (18 em decimal), que é diferente de zero o NUT gera um
Echo Replay com o valor do campo Traffic Class igual a zero (0).
Nº 3 – O NUT passou no teste. Ao receber um pacote Echo Request com o valor do
campo Flow Label igual a 0x34567 (214375 em decimal), que é diferente de zero o NUT
gera um Echo Replay com o valor do campo Flow Label igual a zero (0).
Nº 4 – O NUT passou no teste. Ao receber um pacote Echo Request com o valor do
campo Payload Length igual a 15, gera o Echo Replay correspondente.
Nº 5 – O NUT passou no teste. Ao receber um pacote com o valor do campo Next Header
do cabeçalho IPv6 irreconhecível, gera uma mensagem de erro ICMPv6 (Parameter
Problem message) com o valor do campo Code a 1 (Unrecognized Next Header Type
encountered) e com o campo Pointer a 0x06 (offset do campo Next Header).
Nº6 – O NUT passou no teste. Ao receber um pacote Echo Request com o campo Hop
Limit a zero gera o Echo Replay correspondente, com o valor do campo Hop Limit maior
do que zero (Hop Limit default 64).
Nº 7 – O NUT passou no teste. Ao receber um pacote com o valor do campo Next Header
do cabeçalho Destination Options header irreconhecível (128), gera uma mensagem de
erro ICMPv6 (Parameter Problem message) com o valor do campo Code a 1
(Unrecognized Next Header Type encountered) e com o campo Pointer a 0x06 (offset do
campo Next Header do cabeçalho Destino).
Nº 8 – O NUT passou no teste. Ao receber um pacote Echo Request contendo mais do
que um cabeçalho de extensão, em que o cabeçalho de extensão Hop-by-Hop não
precede o cabeçalho IPv6, gera e envia uma mensagem de erro ICMPv6 (Parameter
Problem message) com o valor do campo Code a 1 (Unrecognized Next Header Type
encountered).
Capítulo V – Resultado dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 83
Nº 9 / Nº 10 – O NUT passou no teste. Ao receber um pacote Echo Request contendo um
cabeçalho Hop-by-Hop com seis Pad1 Option ignora o Cabeçalho de Extensão Hop-by-
Hop, uma vez que o valor do campo Option Type é zero (0) e continua o processamento
do Cabeçalho seguinte que é um Echo Request e, em resposta ao Echo Request envia
um Echo Replay para o TN. Ao receber um pacote Echo Request contendo um cabeçalho
Hop-by-Hop com 6 bytes PadN Option, responde com um Echo Replay para o TN.
Nº 11 – O NUT passou no teste. Ao receber um pacote Echo Request contendo um
cabeçalho de extensão Hop-by-Hop com o valor do campo Option Type desconhecido:
a) Com o campo Option Type igual a 2 (formato decimal), que é equivalente a
00000010 em binário em que os dois bits de maior ordem que especificam a
acção que deve ser tomada caso o NUT não reconheça o tipo da opção são 00, o
NUT ignora o Option Type e continua o processamento do Cabeçalho seguinte
que é um Echo Request e, em resposta ao Echo Request envia um Echo Replay
para o nó de teste. Ou seja a opção desconhecida é ignorada e é processada o
próximo cabeçalho.
b) Com o campo Option Type igual a 66 (formato decimal), que é equivalente a
01100110 em binário em que os dois bits de maior ordem que especificam a
acção que deve ser tomada caso o NUT não reconheça o tipo da opção são 01, o
NUT descarta o pacote Echo Request e não gera nenhuma resposta.
c) Com o campo Option Type igual a 130 (formato decimal), que é equivalente a
10000010 em binário em que os dois bits de maior ordem que especificam a
acção que deve ser tomada caso o NUT não reconheça o tipo da opção são 10, o
NUT descarta o pacote e responde com uma mensagem ICMPv6 (ICMPv6-
Parameter Problem) em que o campo Code é igual a 2 (Unrecognized IPv6
Option encountered) e o campo Pointer é 0x02a.
d) Com o campo Option Type igual a 226 (formato decimal), que é equivalente a
11100010 em binário onde os dois bits de maior ordem (bits mais significativos)
especificam a acção que deve ser tomada caso o nó que processa o pacote não
reconheça o tipo da opção são 11, o NUT descarta o pacote, e como o endereço
destino é um endereço Multicast, não responde com uma mensagem ICMPv6
(ICMPv6-Parameter Problem).
Capítulo V – Resultado dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 84
Nº 12 (a,b) – O NUT passou no teste. Ao receber dois fragmentos enviados (ordem
normal/inversa) pelo TN, reconstitui-os e envia um Echo Replay para o nó de teste (TN),
em resposta ao Echo Request resultante da reconstituição dos dois fragmentos.
Nº 13 – O NUT passou no teste. Ao receber 46 fragmentos do TN, onde os primeiros 45
fragmentos têm o valor do campo Payload igual a 1448 bytes e o último fragmento
contendo o valor do campo Payload igual a 376 bytes, o NUT faz a reconstituição dos 46
fragmentos. Como o tamanho do Payload do pacote reconstituído excede 65.535 bytes, o
NUT descarta o pacote e envia uma mensagem de ICMPv6 (ICMPv6 Parameter
Problem), código zero (0) para o nó de teste (TN).
Nº 14 – O NUT passou no teste. Ao receber apenas um único fragmento contendo a flag
M a 1, o que indica que existem mais fragmentos e passados um intervalo superior a 60
segundos, desde a recepção do primeiro fragmento o NUT descarta o pacote e envia
uma mensagem e de erro ICMPv6 (ICMPv6 – Fragment Reassembly Time Exceeded),
para o TN, ma vez que não foram recebidos fragmentos suficientes para completar a
reconstituição do pacote enviado pelo nó de teste (TN).
Capítulo V – Resultado dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 85
1.4. Comparação entre sistemas operativos
Nesta secção é feita uma descrição detalhada sobre os resultados da execução dos
testes em quatro núcleos diferentes.
Resultado da Implementação do IPv6 no Linux [kernel 2.2.15]. (Teste
retirado da página www.linux-IPv6.org)
Resultado da Implementação do IPv6 KAME, que é avaliada como uma
implementação IPv6 de referência [FreeBSD 3.4].
Resultado da Implementação do IPv6 no Linux nas distribuições testadas
[kernel 2.6.22-14 Ubuntu 7.10 , Kernel 2.6.18-164.el5 -Centos]
Tabela 44 - Teste de Conformidade IPv6 à distribuição Ubuntu e FreeBSD
Da análise aos resultados dos testes de conformidade IPv6 referentes aos núcleos
apresentados na tabela anterior conclui-se que:
O kernel 2.2.15 falhou em 2 testes, porque a implementação do IPv6 no Linux
desse kernel tem um problema na reconstituição dos fragmentos de um pacote
IPv6.
A 1º falha foi devido ao facto do NUT não responder com um
pacote Echo Replay em resposta ao envio de um pacote Echo
Request contendo o Offset = 0 (indica o 1º fragmento) e a Flag M =
0 (Indica que é o último fragmento).
NUT Funcionalidades
Testadas RFC Nº de Testes
Realizados Sucesso Falha Taxa de
Sucesso Kernel 2.2.15 IPv6 Specification 2460 35 33 2 94% FreeBSD 3.4 IPv6 Specification 2460 35 35 0 100% Ubuntu 7.10 (kernel 2.6.22-14-
Generic)
IPv6 Specification 2460 35 35 0 100%
Centos (Kernel 2.6.18-
164.el5)
IPv6 Specification 2460 35 35 0 100%
Capítulo V – Resultado dos testes IPv6 realizados
Exploração da Implementação actual de IPv6 no Kernel do Linux 86
A 2º falha foi devido ao facto do tamanho do Payload pacote
reconstituído pelo NUT exceder os 65.535 bytes e o TN não
receber nenhuma mensagem ICMP (ICMP Parameter Problem).
Como se pode ver na tabela anterior a implementação do IPv6 do
Kame e os outros NUT´s testados passaram nos testes realizados.
Da análise aos resultados dos testes de conformidade IPv6 referentes às
distribuições seguintes: (Centos, FreeBSD e Ubuntu), conclui-se que essas
distribuições se encontram em conformidade com as especificações definidas
no RFC 2460 para os testes realizados.
Exploração da Implementação actual de IPv6 no Kernel do Linux 87
Capítulo VI
Conclusão
1.1. Considerações Gerais
No geral os objectivos propostos para esta dissertação foram alcançados, sendo o
estudo dividido em duas partes: numa primeira, pretendeu-se conferir um enquadramento
teórico ao tema, deste modo, procedeu-se à explicação dos vários componentes do IPv6,
numa segunda, o enfoque foi dado à aplicabilidade prática do IPv6, onde foi feita uma
análise orientada aos detalhes da sua implementação no sistema operativo Linux.
No presente capítulo, pretende-se retratar as conclusões retiradas do estudo realizado,
estabelecendo os objectivos alcançados, as limitações de investigação e a apreciação
final.
1.2. Verificação das hipóteses teóricas e práticas
No que diz respeito às hipóteses teóricas, verifica-se que o IPv6 contém muitas das
características que fizeram o IPv4 ser tão bem sucedido. Apesar de reter os conceitos
básicos do IPv4, o IPv6 procede, por um lado, à modificação de alguns dos pontos
fundamentais tais como: Expansão da capacidade de endereçamento; Simplificação do
formato do cabeçalho; Mecanismos de auto configuração; Melhoria do suporte do
Multicast; Novo tipo de endereço (Anycast); Melhoria do suporte das extensões e da
extensão para autenticação e privacidade (integridade e confidencialidade de dados).
E, por outro, corrige os problemas do IPv4, ao eliminar e/ou tornar opcionais as
funcionalidades do IPv4 que não têm bom desempenho ou que não são frequentemente
utilizadas, conferindo assim uma maior optimização do protocolo IP.
Capítulo VI – Conclusão
Exploração da Implementação actual de IPv6 no Kernel do Linux 88
No que concerne à especificação base, o IPv6 mantém a mesma especificação, contudo,
com algumas alterações, onde se destacam alguns dos RFC´s que foram actualizados e
outros que se tornaram obsoletos.
Todavia, no que diz respeito às hipóteses práticas, a nível da implementação, o
suporte IPv6 no sistema operativo Linux tem variado ao longo do tempo, houve muitas
melhorias e a tendência é de existir cada vez mais funcionalidades implementadas ou
corrigidas. Grande parte das melhorias no suporte IPv6 no Linux resulta da contribuição
dada por organizações tais como WIDE Project, KAME Project e TAHI Project e outras
associações ou grupos de voluntários de diversos países.
A nível prático o estudo realizado consistiu em analisar a implementação do IPv6 no
stack do Linux tendo sido efectuados testes de conformidade em relação à especificação
base do IPv6 definidos no RFC 2460, onde são especificados o cabeçalho IPv6 e os
cabeçalhos de Extensão e Opções.
1.3. Limitações da Investigação
Infelizmente, nem todas as funcionalidades apresentadas no referencial teórico foram
testadas neste trabalho, por forma a evitar um prolongamento das actividades e, ainda,
por força das dificuldades encontradas na implementação de alguns cenários de teste,
principalmente, devido às limitações do ambiente virtual (VMware). Não foi possível
realizar testes de conformidade em relação à especificação do Neighbor Discovery
devido a limitações do ambiente virtual de teste, sendo um dos requisitos de configuração
do cenário de teste, a utilização de uma ligação em série entre o nó de teste e o nó em
teste. Os testes de conformidade efectuados ao longo do presente trabalho incidiram
apenas sobre testes entre hosts.
1.4. Investigações futuras
Nesta secção serão traçadas algumas linhas de orientação sobre perspectivas de
investigações futuras. Em termos de trabalho futuro, deverá ser equacionado:
Testes de conformidade entre host e routers.
Estudar os aspectos relacionados com a segurança no IPv6 e a realização testes
de conformidade sobre o IPsec.
Estudar os aspectos relacionados com a mobilidade no IPv6 e realizar testes de
conformidade sobre o MIPv6.
Exploração da Implementação actual de IPv6 no Kernel do Linux 89
Bibliografia
1. S. Bradner, A. Mankin. RFC1752- The Recommendation for the IP Next Generation
Protocol. [Online] 1995. http://www.ietf.org/rfc/rfc1752.txt.
2. —. RFC 1550 - IP: Next Generation (IPng) White Paper Solicitation. [Online] 1993.
http://tools.ietf.org/html/rfc1550.
3. Morton, David. Understandig IPv6. [Online]
http://www.techsupportalert.com/pdf/c0655.pdf.
4. Comer, Douglas. Computer networks and internets: with Internet applications. s.l. :
Pearson Prentice Hall, 2004.
5. Davies, Joseph. Understanding IPv6. 2002.
6. Windows Server TechCenter. [Online] 2010. http://technet.microsoft.com/en-
us/library/cc738582(WS.10).aspx.
7. Cruz, Ademar. Resumo histórico. [Online] 1999.
http://civil.fe.up.pt/acruz/Mi99/asr/historico.htm.
8. V. Fuller, T. Li. RFC 1338 -Supernetting: an Address Assignment and Aggregation
Strategy. [Online] 1992. http://www.faqs.org/rfcs/rfc1338.html.
9. (CIDR), RFC 4632 - Classless Inter-domain Routing. [Online] 2006. http://www.rfc-
editor.org/rfc/rfc4632.txt.
10. S. Deering, R. Hinden. RFC 2460 -Internet Protocol, Version 6 (IPv6) Specification.
[Online] 1998. http://tools.ietf.org/html/rfc2460#section-4.
11. J. McCann, S. Deering, J. Mogul. RFC 1981 - Path MTU Discovery for IP version 6.
[Online] http://tools.ietf.org/html/rfc1981.
12. Nordmark, E. RFC 2765 - Stateless IP/ICMP Translation Algorithm (SIIT). [Online]
2000. ftp://ftp.rfc-editor.org/in-notes/rfc2765.txt.
Exploração da Implementação actual de IPv6 no Kernel do Linux 90
13. Bieringer, Peter. Linux IPv6 HOWTO. [Online] http://tldp.org/HOWTO/Linux+IPv6-
HOWTO/.
14. K. Nichols, S. Blake,F. Baker. RFC 2474 - Definition of the Differentiated Services
Field in the IPv4 and IPv6 Headers. [Online] http://tools.ietf.org/html/rfc2474.
15. Linux IPv6: Which One to Deploy. Haddad, Ibrahim. 2002.
16. [Online] http://www.tahi.org/.